You can clone with
HTTPS or Subversion.
deAtog uses the following flags on one of his sites:
$.mobile.changePage.defaults.changeHash = false;
$.mobile.hashListeningEnabled = false;
$.mobile.pushStateEnabled = false;
He tried to use a popup and noticed that the navigation wasn't working. In the process of trying to make the popups work the same way as dialogs when the above-mentioned flags are set, I ran across the bug at http://jsbin.com/omacox/133.
Since hash manipulation is off, the dialog hash key is not added when the dialog appears, and the dialog's close button does a window.history.back() by default. This causes the browser to go back to the page before the one that launched the dialog.
I'd add a special case to the dialog widget's close() method, but I don't really know what else we could do instead of window.history.back() to close the dialog and return to the page that launched it.
This is a tricky one. It seems critical to have the back button close the popup, especially on platforms that have back button keys but if hash listening is off, there's no way to make this work. If someone wanted to make this work in this setup, they really hould include a "x" close button and have that manually close the popup via JS and ensure that clicking out does the same. We rely on using window.history.back for all these cases by default but if there was some way to not call this when listening is disabled, that might be all we can/should do on our end. We could provide a demo page showing how to handle this correctly in these cases. What do you think @gabrielschulhof?
BTW - should the title say "popup" not "dialog" or is this really an issue for both anyway?
It's an issue with the dialog and not the popup.
If the user hits the back button in the browser, there's really nothing we can do if hash listening is disabled. But, if the usre clicks the (X) button, then the dialog widget's close() method gets called, which blindly calls window.history.back(). So, while we cannot prevent the back button from going to the page before previous, we have control over the body of the dialog widget's close() method - so we can make it do something else if those flags are set.
@gabrielschulhof - makes sense to me. I think it makes sense to try and be smarter with the 'x' button in these conditions. Won't be fool-proof because we can't control the back button, but this will at least be as solid as we can make it on our end.
There's another problem: docs/pages/dialog.html gives an example of a dialog with two buttons, both of which have an href to a page that no longer exists, but because they also have data-rel="back", they go back in history. So, buttons like these should also be avoided on dialogs. The docs might need to be changed.
So this is just something we can add to the docs as a note near the bottom of the overview page for dialogs. It's certainly an edge case to have AJAX on but hashchange listening off. Presumably, you're shutting this off because you have your own hashchange listener going, otherwise, you've configured things in a way that will be pretty broken. Maybe @agcolom can add a quick note to the docs.
[dialog] When hashListeningEnabled is not set, use urlHistory to go b…
…ack from the dialog - Fixes: #4320
So, ummm ... can we close this issue, or shall we wait for @agcolom to weigh in on the docs side?
@gabrielschulhof @toddparker Hi sorry just had 2 crazy days at work so will have to catch up with JQM things... . Should be better from now on.. Happy to add a note in the docs. We need to also make clear distinction between popups and dialogs as I can see the obvious question: what is the difference between the two :-) If there are links to pages that no longer exist, the links must be removed in we also care about grade c devices and in general good design rules.
I think we can close this issue ...