Issue: all types of popup seem to close immediately after being opened in the Chrome Browser App on both iPhone (4S and 5) and iPad 2 (all with iOS6)
I came across this issue when coding with jQuery Mobile 1.2.0 and jQuery Core 1.8.2 and noticed that it can be reproduced by visiting the documentation for popups in the Chrome Browser on the above devices (so figured it probably wasn't my code at fault):
Clicking on any of the example buttons/links in the documentation opens a popup and then immediately closes the popup (when the expected behavior would be the for popup to stay visible until closed by the user)
Thanks for reporting the issue. Can you also reproduce it with latest code? http://jquerymobile.com/test/docs/pages/popup/index.html
I just tried the '/test/docs/' link on both iPad 2 and iPhone 5 and it does now seem to open and keep open the popups - which is good. However, on closing the popup it seems to refresh the 'previous' page in its entirety (i.e. screen goes blank as if doing a non ajax reload and page position is lost) rather than just hiding the popup.
Also, as a weird side note the original '1.2.0' link I posted yesterday now seems to behave the same as the 'test' link on the iPad 2 (i.e. popup stays open but seems to reload page on close) however on the iPhone 5 the '1.2.0' link still seems to immediately hide the popup after opening.
I've often seen the '/test/' documentation links in search results and wondered what they are. Is this the latest in progress code that has not yet been released?
Thanks for testing again.
Yes, "jquerymobile.com/test" uses latest code. Every time we commit a change/fix to branch "master" the result will be visible on "/test" within a few minutes.
"jquerymobile.com/demos/1.2.0/docs/" uses the stable code of the 1.2 release and will never change. So if there is a bug in there, it will still be in there the next day. The issue you noticed might be caused by a race condition. Anyway, we are going to look into it.
I tested both 1.2 and master and both have this issue, although there are slight differences. I can't think of a reason why Chrome is any different than Safari because it has to use the same browser engine. In fact, aren't these just standard web views? In any case, we'll give thus a look, it's a serious issue.
@toddparker iOS chrome is just a web view i checked in a normal ios web view and this problem does not show so this is a weird one. not sure how they could actually be different?
I see problems in chrome as well with popup's (iphone 4 ios5) popups open fine and stay open however when i close a popup it causes the whole page to reload
UPDATE: i get this issue on ipad 2 ios6 also
@johnbender, when I open the root page of the old docs and I click on any page, it goes to that page, but it does not create a history entry for it.
At this point you're back on the blank tab page, rather than http://jquerymobile.com/test ...
We are setting location.hash, but it does not result in a new history entry!
I think we need to disable history for iOS Chrome. If setting a hash does not result in a new history entry, I'm not sure what else we can do with the location to create a new history entry that does not also reload the page.
It's kinda strange that nav behaves that way since a simple test page works.
Does this page also exhibit the popup-closes-immediately behaviour?
I've disabled popup history tracking on that page, and I've restricted the screen click handler to only work when the popup is open, in case it gets a stray button-up event as soon as the popup starts to open.
@gabrielschulhof that test page seems to work fine. Popup stays open and then when user closes the popup it just closes (rather than reloading the page - like on the other test link)
@johnbender OK so a history entry is probably being created, but when the user clicks back from it, we're probably issuing an additional $.mobile.back or something and we end up overshooting ...
This problem does not happen in 1.2.0.
iOS Chrome seems a little popstate-happy. I added a console.log to navigator's popstate handler, and what happens is this:
On initial page load, you get two popstate events.
When you set the hash, it is followed by a popstate event.
When you hit the back button, nothing more is recorded, but it jumps to the empty tab page.
On the desktop, Chrome behaves more rationally:
On initial pageload you get one popstate event.
There are no popstate events when you set the hash.
There is one popstate event when you hit the browser's "Back" button.
It does not navigate all the way back to the empty tab when pushState is disabled. We might have to disable pushState on iOS Chrome.
Considering that the going-back-to-the-start-page is happening in both 1.2.0 and master, I'd say the cause is not the nav refactor, but a bad pushState implementation in iOS Chrome. We should disable pushState for iOS Chrome.
I think I will close this and designate #5414 the umbrella issue.