Dialog transitions should leave previous page visible

[scottjehl]

With the exception of slide and flip, dialog transitions should leave the previous page visible underneath the dialog page (showing through the dialog's page background screen).

To do this, we could possibly add a class to the previous page that keeps it display block after the ui-page-active class is removed.

This class addition might be most easily achieved through a new option of $.mobile.changePage called "hidePrevPage", which would default to true, but could be false in the case of dialogs. In that way, the option wouldn't be specific to dialogs.

Once this option is available, and pages use webkit overflow scrolling (where supported, e.g. iOS5, per this ticket: #2210), dialogs will appear to fade-in in place, on top of the page, without jumping to top first.

[anpsince83]

I think it would be nice if the the "hidePrevPage" option was false, it would prevent the page show/hide events from firing on the previous page that opens the dialog - or have an additional option that accomplishes this.

There are several instances where I have a page open a dialog, but I want to keep the previous page in its current state, but because of the show/hide events, the page gets manipulated when leaving to and returning from the dialog. That way the dialog would truly act like a dialog.

Before I open the dialog I put a flag on the current page to tell my show/hide events not to fire, but it would be nice if something like this could be built into the framework.

[tqc]

Returning to the parent page of a dialog is actually the same as showing a page that hasn't been removed from the DOM - you want pageshow to run with code that updates the existing controls with any changes to application state rather than recreating the controls, which belongs in pagecreate.

In my experience dialogs almost always have some effect on the state of the parent page.

[anpsince83]

@tqc, I agree that the dialog most often will have an effect on the parent page, I don't think you will necessarily always want the parent's page show/hide events running when opening a dialog or returning from one.

For instance in our app, the parent page gets populated on pagebeforeshow with data that is a result of parameters set on the previous page and the page controls are reset on pagehide. So if you return to the parent page from the dialog its pagebeforeshow event will run, but the page has already been populated with data and the parameters that are set in the previous page are missing, because you are returning from the dialog. Or when you open the dialog, the pagehide event is run, and the controls are reset.

I think it would be more logical to suppress the parent's show/hide events when opening/returning from a dialog. And use the dialog's pagebeforehide or pagehide event to manipulate the parent page.

[johnbender]

@tqc @scottjehl @anpsince83

The only problem I have with assuming we shouldn't reload the underlying page when going back to it is that if someone does in fact want to have it reloaded they can, and, in the case where they don't want it to be reloaded/reaped they can simply decorate the page with data-dom-cache=true.

To put it another way, you can have it behave either way right now by altering the markup if you need to but if we make it the default to retain the page it'll be much harder to remove it and have it refreshed by the server.

With all that said, this doesn't address the visual issues.

[anpsince83]

@johnbender, I actually have data-dome-cache=true set on my parent page to maintain its state, but unfortunately its pageshow/pagehide events still fire which results in page manipulations that are not wanted.

IMHO, even though a dialog is actually another page, I think it would be great to have an option added to $.mobile.changePage that when combined with opening a dialog allows the parent page to remain in the DOM and it's pageshow/pagehide events do not fire. That way it truly acts like a dialog, and is a modal that leaves the page below untouched.

[johnbender]

@anpsince83

I'll concede that the semantics of pageshow and pagehide are up for debate when showing a dialog but I think the behavior would be equally confusing for someone who's expecting pagehide when a dialog comes up. Maybe a third event (pageblur?) where a dialog or custom select menu is raised and the previous page persists behind it. Spitballing.

[edit] sentence clarity

[anpsince83]

@johnbender, I can definitely see the argument both ways when it comes to pageshow and pagehide. That is why I think it would be beneficial to have an option that accomplishes one or the other (leave the page visible no events fired or page removed from DOM) that way the developer can decide on the behavior.

[tqc]

@johnbender @scottjehl @anpsince83

Is the issue the difference between single and multiple page apps? I use multiple html files, which makes create/show behave much like the show/blur described here. An additional event that appears to do the same as an existing event may be confusing.

I haven't looked into the code to see how easy it would be to implement, but adding some additional information to the pageshow event could help - either the id/role of the previous page or a flag indicating that the transition was triggered with back. With this information the pageshow handler can easily determine that the page state hasn't changed since it was last shown and skip the update.

Though I disagree with @anpsince83 on updating parent pages directly from dialogs, the reference to the previous page would also be useful in that context.

[toddparker]

We're working on a new widget called popup that is basically a container that sits over a modal layer and can contain any content, widget or even a dialog which should fill this request.

[toddparker]

#3218

[micheljansen]

I was under the impression that a dialog was always supposed to be modal. What is the difference between a page, a dialog and a popup?

[toddparker]

Right now, a dialog is really a completely separate page that is designed to look modal,but isn't really sitting over the previous page. This ticket was opened to really open the dialog over the previous page so you could see the other page a bit. I do wonder if we need this now that we have popup in the works which is a true modal overlay. @scottjehl - think we should close?

[jaspermdegroot]

@toddparker @scottjehl - Can I close this one?

[toddparker]

I think the new popup widget accomplishes this request nicely so I'm going to close. Tagged as a feature request so we can keep this on our radar.