Reloading pages after a dialog breaks navigation #5122

Closed
MauriceG opened this Issue Oct 3, 2012 · 7 comments

Comments

Projects
None yet
4 participants
Contributor

MauriceG commented Oct 3, 2012

Issue description:
Reloading pages after a dialog breaks navigation and the dialog url is kept in history

Test page:
http://test.jqmobile.de/dialogReload/index.html

Steps to reproduce:

  1. Go to the demo, 2. open the dialog, 3. goto page 2, 4. reload the page, 5. go back to page 1, 6. open the dialog

Expected outcome:
The dialog should open even after a page reload

Actual outcome:
The dialog does not open anymore after reloading a page after the dialog

Platforms/browsers (including version) and devices tested:
Safari 5.1.7 / Win, Safari iOS 6 iPad 3 and iPhone 4S, Chrome 22 Win, FF 14 and 15 Win, Opera 11.64 Win, Opera Mobile Emulator

jQuery Mobile and jQuery core version used:
jQueryMobile latest -- Core 1.8.2

Other relevant information:
Same scenario works with popups: http://test.jqmobile.de/dialogReload/ppp.html

Contributor

scottjehl commented Oct 22, 2012

The idea of dialogs is to not be open after page load, so this is expected behavior. It would be easy enough to disable this behavior through an option if desirable, but we built dialogs to satisfy the following guidelines:

  • Open an external document with all typical "page" properties, but a different visual treatment.
  • Update the URL using a known, null-value has (even in pushstate-supporting browsers) so that the dialog can be dismissed via the back button, but not reachable through a link.
  • When a URL containing a dialog hash is opened, the page that is listed prior to the null dialog hash should be shown.

Are we reconsidering these goals now? If not, should we close this out as wontfix?

Thanks!

/cc @johnbender

Contributor

toddparker commented Oct 22, 2012

I think the issue is with you're 3rd bullet. The framework does indeed hop back to the page before the dialog (page 1) but the URL isn't cleaned up properly and has a &ui-state=dialog tacked on when it shouldn't.

Contributor

scottjehl commented Oct 22, 2012

I guess when navigating forward to a new page from a dialog, we could replaceState to the current URL sans &ui-state=dialog before progressing? Maybe we should clarify the issue if that's the part we want to fix.

Contributor

toddparker commented Oct 22, 2012

Yep, think that's it. Right now, it possible to break things by just opening a popup, then refreshing. The framework will route you back to the previous page because we don't allow for deep-linking to dialogs but the URL still has the &ui-state=dialog and we need to clean that up. If we don't, then if you try to open another dialog, it fails because we already have that in the URL.

Contributor

toddparker commented Oct 22, 2012

@MauriceG - Are you tinkering with the code in these demos or it is just stock links? In your demo, opening a popup and refreshing also kills all future popups, no need to do that long chain. However, when I tested that scenario in 1.1, 1.2 and latest, I can open a popup, refresh and open another popup just fine. What's the difference?

http://jquerymobile.com/demos/1.1.1/docs/pages/page-dialogs.html
http://jquerymobile.com/demos/1.2.0/docs/pages/dialog/index.html
http://jquerymobile.com/test/docs/pages/dialog/index.html

Contributor

toddparker commented Oct 22, 2012

Actually, maybe I was wrong. Refreshing a dialog on your test page is working ok. False alarm.

Owner

arschmitz commented Dec 14, 2012

No response on this in two months and the issue did not seem to be clear . going to close as stale

arschmitz closed this Dec 14, 2012

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