Skip to content
This repository

Dialog returning to page before previous when certain flags are set #4320

Closed
gabrielschulhof opened this Issue May 09, 2012 · 10 comments

3 participants

Gabriel "_|Nix|_" Schulhof Todd Parker Anne-Gaelle Colom
Gabriel "_|Nix|_" Schulhof
Collaborator

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.

Todd Parker

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?

Todd Parker

BTW - should the title say "popup" not "dialog" or is this really an issue for both anyway?

Gabriel "_|Nix|_" Schulhof
Collaborator

It's an issue with the dialog and not the popup.

Gabriel "_|Nix|_" Schulhof
Collaborator

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.

Todd Parker

@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.

Gabriel "_|Nix|_" Schulhof
Collaborator

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.

Todd Parker

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.

Gabriel "_|Nix|_" Schulhof
Collaborator

So, ummm ... can we close this issue, or shall we wait for @agcolom to weigh in on the docs side?

Anne-Gaelle Colom
Collaborator
agcolom commented May 16, 2012

@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.

Gabriel "_|Nix|_" Schulhof
Collaborator

I think we can close this issue ...

Gabriel "_|Nix|_" Schulhof gabrielschulhof closed this May 29, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.