Skip to content
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.

Child dialog opened from parent dialog closes with reverse transition of parent dialog #4951

Closed
dcarrith opened this issue Sep 7, 2012 · 0 comments

Comments

@dcarrith
Copy link
Contributor

dcarrith commented Sep 7, 2012

Jsbin seems to be having issues at the moment so I can't create a sample to demonstrate the issue.

This only happens with the close button that is automatically added during enhancement. I don't mean to go on a tangent, but that brings up another thing that might be an issue. If I manually add an <a> element to the markup of the dialog page that serves as the close button, the close button that gets automatically added during enhancement should not get added at all. Currently in 1.2 beta, if I have my own <a> element with all the attributes it needs and a class of ui-btn-right, then there will also be one on the left that is automatically added. If I have my own <a> element with a class of ui-btn-left, then there will end up being two close buttons on the left because of the one that gets automatically added over top of it.

Anyway, back to the issue "Child dialog opened from parent dialog closes with reverse transition of parent dialog."

The culprit seems to be the hashchange listener that's triggered as a result of a call to window.history.back() in the close function of the https://github.com/jquery/jquery-mobile/blob/master/js/widgets/dialog.js.

For reference, here are lines 43-51 of https://github.com/jquery/jquery-mobile/blob/master/js/widgets/dialog.js

// this must be an anonymous function so that select menu dialogs can replace
// the close method. This is a change from previously just defining data-rel=back
// on the button and letting nav handle it
//
// Use click rather than vclick in order to prevent the possibility of unintentionally
// reopening the dialog if the dialog opening item was directly under the close button.
headerCloseButton.bind( "click", function() {
    self.close();
});

The call to self.close() results in lines 90-92 of the same file being executed when hashListeningEnabled equals true

if ( $.mobile.hashListeningEnabled ) {
    window.history.back();
}

For whatever reason, that causes the child dialog to close with the reverse of the transition that was used to open the parent dialog rather than using the reverse of the transition that was used to open the child.

If I override $.mobile.hashListeningEnabled = false, then the issue goes away. Similarly, if I add a data-rel='back' to the headerCloseBtn markup on line 21 of of https://github.com/jquery/jquery-mobile/blob/master/js/widgets/dialog.js file, then the issue also goes away. But, apparently the data-rel='back' attribute was removed in exchange for using an anonymous function (which calls self.close()) so that "select menu dialogs can replace the close method." The comment goes on to say "This is a change from previously just defining data-rel=back on the button and letting nav handle it."

gabrielschulhof pushed a commit that referenced this issue Jul 24, 2014
Our history entries contain exactly one transition: The one used to arrive at
the entry. In addition, the index of the current entry and that of the previous
entry is updated before the value for the transition is computed. So, it makes
sense, when going backwards, to read the transition value from the previous
entry, because that value stores the transition that was used to get there from
where history is currently at.

However, when going forward, it makes no sense to read the transition value
from the previous entry, because that one stores the transition that was used
to reach it, not the transition that must be used to reach the next entry.

Closes gh-7485
Fixes gh-1867
Fixes gh-4951
agcolom pushed a commit to agcolom/jquery-mobile that referenced this issue Nov 26, 2014
Our history entries contain exactly one transition: The one used to arrive at
the entry. In addition, the index of the current entry and that of the previous
entry is updated before the value for the transition is computed. So, it makes
sense, when going backwards, to read the transition value from the previous
entry, because that value stores the transition that was used to get there from
where history is currently at.

However, when going forward, it makes no sense to read the transition value
from the previous entry, because that one stores the transition that was used
to reach it, not the transition that must be used to reach the next entry.

Closes jquery-archivegh-7485
Fixes jquery-archivegh-1867
Fixes jquery-archivegh-4951
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant