You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.
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."
// 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."
The text was updated successfully, but these errors were encountered:
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.
Closesgh-7485Fixesgh-1867Fixesgh-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.
Closesjquery-archivegh-7485Fixesjquery-archivegh-1867Fixesjquery-archivegh-4951
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
The call to self.close() results in lines 90-92 of the same file being executed when hashListeningEnabled equals true
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."
The text was updated successfully, but these errors were encountered: