Behavior change with dev2 release

0 views
Skip to first unread message

ltlfrari

unread,
Dec 18, 2009, 5:55:53 PM12/18/09
to iui-developers
I just switched my app to 0.40 dev2 and I noticed a behavior change on
my iPod when submitting forms.

When I was using the 0.31 version I had modified the submitForm
function so that it did a form.submit if the form had redirect="true"
on it, otherwise iUI always subbed it via Ajax.

I am using a number of redirects, both from the server and via
javascript invoked by toolbar buttons to isolate my 'login' and
'logged out' pages from the main app. Once you login you get
redirected to the main app, If you logout, you get redirected to the
logout screen and there's a login button that does window.location
redirect to the login screen.

So the cycle is pretty much:

Open app:
Server side login script runs and you get
Login screen (complete screen, head, scripts, the lot!)
Hit submit button , form subbmitted via form.submit.
Backend sends redirect to main screen
client invokes main screen, complete new screen.

Hit logout button on tool bar which runs a javascript function.
Function does a window.location redict to my logout script on the
server
Server sends a complete 'you are logged out' screen (head, javascript
css etc)
Screen has a 'login' button in the toolbar that runs a javascrpt
function that does a window.location redirect to my server side login
script.
Then you are back to the start.


With my modifed ver of 0.31 iUI this all worked fine and I could do
that all day.

I found out that I could code taget="_self" on form to get the
required form submission behavior with the 0.40 release of iUI so I
switched to that.
However I have found that with the 0.40 release (dev1 and dev2), the
above works ok through one cycle once then the next time you hit the
submit button on the login screen, a new safari browser window opens
and my apps login screen appears in the new window, complete with
address bar!

So the sequence is now:

Open app:
Server side login script runs and you get
Login screen (complete screen, head, scripts, the lot!)
Hit submit button , form subbmitted via form.submit.
Backend sends redirect to main screen
client invokes main screen, complete new screen.

Hit logout button on tool bar which runs a javascript function.
Function does a window.location redict to my logout script on the
server
Server sends a complete 'you are logged out' screen (head, javascript
css etc)
Screen has a 'login' button in the toolbar that runs a javascrpt
function that does a window.location redirect to my server side login
script.
Server side login script runs and you get
Login screen (complete screen, head, scripts, the lot!)

Hit submit button and the login screen opens again in a NEW browser
window, complete with address bar and the address bar appears on the
old window as well.

I found that if I added event.preventDefault() to the form submission
code around line 306 it works fine.

else if (link.getAttribute("type") == "submit")
{
var form = findParent(link, "form");
if (form.target == "_self")
{
form.submit();
event.preventDefault(); // DEE 12/18/09 - Fix behavior
change
return; // allow default
}
submitForm(form);
}


Don't know if this is the right place to post this but after
struggling and failing to convert my app to work with jQTouch I really
want it to work with iUI which is what I originally developed it with.
Just thought I'dput this up to at least document the issue.

Thanks

Dave E

Sean Gilligan

unread,
Dec 19, 2009, 9:11:25 PM12/19/09
to iui-dev...@googlegroups.com
Hi Dave,

> Don't know if this is the right place to post

It' the right place.


> Just thought I'dput this up to at least document the issue.
>


Thanks for the report. I'm need to do a more thorough review of the
form handling code as some of the comments might indicate. Right now, I
don't understand what could be happening. It doesn't make sense to me.

I have a few questions:

1) Have you made any mods (at all) to iui.js?
2) Are you doing anything in JavaScript that might be interfering with
iUI's operation?
3) Can you reproduce the problem in a simple test case?
4) Take a look at http://iui-js.appspot.com/test/form-test.html - what
are you doing differently from these test cases?

Which brings up the big question I have - why does it work the first
time, but not the second time. When reloading the login screen, what is
different from the first time ... a cookie a query parameter?

Thanks,

Sean

ltlfrari

unread,
Dec 20, 2009, 1:30:56 PM12/20/09
to iui-developers
No mods when it fails, standard 0.40 dev1 or dev2 versions give the
same result.

jQuery is being pulled in to the intermediate screen but not the login/
logout screens and those are full screen reloads so it should not be
even loaded into the dom on the login screen.

Above scenario is about as simple as I can get. I can't even make a
demo available because my back end need access to my companies
intranet for the front end to work.

There is one cookie that's being moved around between the screen
sessions to track the login state, cookie gets deleted on logout.

As for why the first time and not the second, I have no idea at this
point. It only occurs when invoked via the iPod, everything 'seems'
fine when using Safari on my desktop in that it does not try to open
another browser window or tab.

The only thing I can think of that I am doing differently is that I am
using both backend (302 resp)and front end (via js window.location) to
cause complete page reloads when switching from the login process to
the main app screen and from the main app screen to the logout
process.

I'll see if I can put a simple app together that suffers from the same
problem tat I can upload or make available so you can see it failing
in action.

Dave E

Remi Grumeau

unread,
Dec 20, 2009, 7:26:37 PM12/20/09
to iui-dev...@googlegroups.com
Remember that cookies/sessions are stored in the header of page.
If you login page create a cookie and a initialize a session, you have to reload the page to do it properly so page headers are reloaded (sessions and cookies vars included).

Of course you can use some ajax calls but we are talking here about a secure access right ? :)

Remi

> --
>
> You received this message because you are subscribed to the Google Groups "iui-developers" group.
> To post to this group, send email to iui-dev...@googlegroups.com.
> To unsubscribe from this group, send email to iui-developer...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/iui-developers?hl=en.
>
>

ltlfrari

unread,
Dec 20, 2009, 10:08:12 PM12/20/09
to iui-developers
Whenever a cookie is being set, a complete page is being sent. After
that, the form submission, even via ajax causes the cookies to get
sent to the back end.

I tried creating a 'test' (ie cut down version) version of my code but
that behaves differently from my problem scenario. It now opens the
new page when I click the submit button on the initial login page.
Totally weird since there's no real difference in the overall
functionality of the code (although obviously I've hacked a few things
around for the test) but it should work the same and it doesn't (don't
you hate that!).

I can zip up my test code and post it somewhere if you like (mostly
perl though) but otherwise for now I have other stuff I need to work
on with my app and I have the workaround I described in my initial
post.

It could well be my code (probably is) since I am doing all these page
redirects, it could be jquery sticking it's nose in there but at this
point I don't think I am going to spend any more time on it. I have a
project coming up early next year that I need to get ready for.

Dave E

Sean Gilligan

unread,
Dec 22, 2009, 4:51:40 PM12/22/09
to iui-dev...@googlegroups.com
ltlfrari wrote:
>
> I can zip up my test code and post it somewhere if you like (mostly
> perl though) but otherwise for now I have other stuff I need to work
> on with my app and I have the workaround I described in my initial
> post.
>

Do you mind creating an Issue for this problem (you may want to search
for "form") in the Issued DB to see if there are similar reports (I am
not ware of any) You could then zip up your test code and attach it to
the Issue.

The ideal reduction would be a static page that reproduces the issue.
Producing a static page is sometimes difficult, but it is usually
possible. If we can reproduce it and narrow it down to something
specific I'll add it to the form tests in the tests directory of iUI.

> It could well be my code (probably is) since I am doing all these page
> redirects, it could be jquery sticking it's nose in there but at this
> point I don't think I am going to spend any more time on it. I have a
> project coming up early next year that I need to get ready for.
>

Thanks for reporting it. I'll keep an eye open.

-- Sean

ltlfrari

unread,
Dec 22, 2009, 5:54:24 PM12/22/09
to iui-developers
I fixed it (sort of) in my code instead of modifying iUI.

Basically I had to make the anchor submit button on the login form
look like this:

<a class="whiteButton" type="submit" href="javascript:{return
false;}">Login</a>

The js in the href just makes it cancel the default action, which is
all that the mod I made above to iuI.js did anyway.

By the way, the sample form "post to _self" test at
http://iui-js.appspot.com/test/form-test.html#_formTest does NOT work
on my iPod Touch although it does in Safari on my windows desktop.
Seems like you HAVE to have an href=something tag in there for it to
work on the real device. On my iPod the button just does not work at
all, seems to do nothing. Just my observation.


Sean Gilligan

unread,
Dec 22, 2009, 6:08:02 PM12/22/09
to iui-dev...@googlegroups.com
ltlfrari wrote:
> I fixed it (sort of) in my code instead of modifying iUI.
>
> Basically I had to make the anchor submit button on the login form
> look like this:
>
> <a class="whiteButton" type="submit" href="javascript:{return
> false;}">Login</a>
>
> The js in the href just makes it cancel the default action, which is
> all that the mod I made above to iuI.js did anyway.
>
> By the way, the sample form "post to _self" test at
> http://iui-js.appspot.com/test/form-test.html#_formTest does NOT work
> on my iPod Touch although it does in Safari on my windows desktop.
>

Wow! It doesn't work in the Simulator (v. 3.1.1), either. The perils
of relying too much on desktop Safari for development and testing...

I'll look into it.

-- Sean

Sean Gilligan

unread,
Dec 28, 2009, 4:19:09 PM12/28/09
to iui-dev...@googlegroups.com
Sean Gilligan wrote:

> ltlfrari wrote:
>
>> By the way, the sample form "post to _self" test at
>> http://iui-js.appspot.com/test/form-test.html#_formTest does NOT work
>> on my iPod Touch although it does in Safari on my windows desktop.
>>
>>
>
> Wow! It doesn't work in the Simulator (v. 3.1.1), either. The perils
> of relying too much on desktop Safari for development and testing...
>
> I'll look into it.
>

I spent some time studying this issue and I don't understand why it is
not working in Mobile Safari (I was testing on Simulator 3.1.1, I also
quickly confirmed it didn't work in 3.0 or 2.2.1 either) It appears
that for some reason the onclick handler is not getting called for the
"post to _self" test. I also noticed that setting (even a no-op)
onclick handler for the containing form, like this:

form.onclick = function(event)
{
};

seems to fix the problem. I don't understand why this would be
necessary. I also don't understand why Mobile Safari would/should be
any different from Desktop Safari in this case.

-- Sean

Reply all
Reply to author
Forward
0 new messages