Dialogs should not be part of url or page history

[cyrret]

This is per the documentation (http://jquerymobile.com/demos/1.1.0/docs/pages/page-dialogs.html)...as well as just good UX practice in general.

Currently if multiple dialogs are open, multiple &ui-state=dialog are appended to the url, and all the dialogs are part of the nav stack. As a result, the user will need to close each dialog, one at a time, to get back the page the dialogs are contextual to.

If the user has to tap through to close a bunch of dialogs (a la Windows or pre-iOS 5), a dialog is probably the wrong widget for the use case.

I have an "almost ready fix" for this on my fork: https://github.com/cyrret/jquery-mobile. If you guys want to keep the existing behavior where dialogs are part of the page history, there should at least be configuration that can disable this. If need be, I can create said configuration and modify my fix accordingly.

[johnbender]

@cyrret

We have to alter the browser history in some fashion to enable the back button for dialogs. That is, we could use pushState (though I'm not 100% on whether that works with the same url) but it was previously broken in older versions of iOS which is why we use replaceState which requires an already altered url.

You said yourself that if they have to tap back through a bunch of dialogs they're probably using the wrong widget :D

Given the requirement that the back button work with dialogs I'm going to close this issue. If you can propose an alternate solution that takes that into account feel free to post back.

[cyrret]

Can you better explain the requirement that the back button work with dialogs? I may be able to propose an alternate solution once I better understand this requirement.

My solution supports the back button, what is does not support is keep a history of all open dialogs. It only remembers the last one opened.

What I mean by "using the wrong widget" is in the case where the UX depended on having a history of all open dialogs. Given the current release of jQuery, it would be very easy for the user to get in a state where they have a bunch of dialogs open, especially when the dialogs are triggered by user behavior. In my mind the most elegant behavior for this situation is to only have "record" in the history of the most recently opened dialog.

Thanks!

[johnbender]

@cyrret

"Dialogs should not be part of url or page history"

I think my confusion arises from the title because they have to be a part of the browser history in some fashion or another to support the back button. Because we have to alter the url somehow to create a new history entry, is the win here not tacking on extra dialog states to the hash? ie confining it to #&ui-state=dialog instead of #&ui-state=dialog?

Either way we'd likely wait until 2.0 because of the way this breaks backward compat so drastically in terms of behavior.

[cyrret]

The win here is primarily in usability for the end-user. The url history was just something I additionally noticed that seemed a bit funky. Perhaps a specific example will clarify things...

Current state:

1. Let's say the end-user opens 3 dialogs successively, Dialog A, Dialog B, and Dialog C.
2. The url looks like this at the end of these 3 dialog opens: http://somepage.com/#&ui-state-dialog&ui-state-dialog&ui-state-dialog
3. At this point, if the user clicks the dialog's close button or browser back, Dialog B will be shown. And the url looks like this: http://somepage.com/#&ui-state-dialog&ui-state-dialog.
4. Closing dialog B or hitting browser back again shows Dialog A and this url: http://somepage.com/#&ui-state-dialog.
5. Closing dialog A or hitting browser back again will finally yield the original page with the original url.

With my patch:

1. The url looks the same after 1, 2, or 3 successive dialog opens: http://somepage.com/#&ui-state-dialog.
2. Hitting browser back or closing the dialog after any number of dialog opens always just goes back to the original page.

Does that make sense?

RE: backwards compatibility. I understand and agree this is a valid concern. At the same time, I don't want to leave my patch hanging for that long, and believe it could help many developers pre-2.0. What if my "no-history" patch behavior were off by default, and I added an html attribute to called "data-omit-from-history" that could enable this on a per-dialog-basis?

Alternatively, I could also add a javascript attribute to $.mobile to enable this for all dialogs (disabled by default again).

Would you consider that safe to pull in?

Thanks again.

[cyrret]

Hey, I just wanted to follow up on this. Do any of my suggested alternatives seem appropriate to pull in? Thanks.

[johnbender]

@cyrret

Points well taken. I'll ask the rest of the team.

[cyrret]

Thanks John, let me know.

[jaspermdegroot]

@johnbender @gabrielschulhof - Did we already make a decision about this?

[arschmitz]

the dialog widget is being deprecated in favor of just a specially styled page so im closing this