New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
3 participants
@gabrielschulhof
Contributor

gabrielschulhof commented May 9, 2012

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.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 13, 2012

Contributor

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?

Contributor

toddparker commented May 13, 2012

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?

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 13, 2012

Contributor

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

Contributor

toddparker commented May 13, 2012

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

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof May 13, 2012

Contributor

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

Contributor

gabrielschulhof commented May 13, 2012

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

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof May 13, 2012

Contributor

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.

Contributor

gabrielschulhof commented May 13, 2012

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.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 16, 2012

Contributor

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

Contributor

toddparker commented May 16, 2012

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

@ghost ghost assigned gabrielschulhof May 16, 2012

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof May 16, 2012

Contributor

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.

Contributor

gabrielschulhof commented May 16, 2012

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.

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 16, 2012

Contributor

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.

Contributor

toddparker commented May 16, 2012

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.

gabrielschulhof added a commit that referenced this issue May 16, 2012

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof May 16, 2012

Contributor

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

Contributor

gabrielschulhof commented May 16, 2012

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

@agcolom

This comment has been minimized.

Show comment
Hide comment
@agcolom

agcolom May 16, 2012

Member

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

Member

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.

gabrielschulhof added a commit that referenced this issue May 16, 2012

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof May 29, 2012

Contributor

I think we can close this issue ...

Contributor

gabrielschulhof commented May 29, 2012

I think we can close this issue ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment