Fix dialog double hash try2 #4117

Merged
merged 2 commits into from Apr 19, 2012

Projects

None yet

2 participants

@gabrielschulhof
Collaborator

This is another approach to avoiding the need to close a dialog twice.

The idea is: If the current urlHistory item contains &ui-state=dialog, but the current page is not a dialog, then no hash change is made and no urlHistory entry is created when changePage loads a dialog into such a state. IOW, the state is reused.

Note that the first commit of this PR (851fad0) is also useful for the popup widget, because it fixes a silent problem that's currently present: The urlHistory is moved forward to an entry of type &ui-state=dialog when the user clicks "Forward" towards a location that is no different from the current location except for &ui-state=dialog, but it is not moved back when the user clicks "Back" from such a location.

The popup widget was implementing its own version of this move-urlHistory-back-from-a-dialog-state, but putting it in navigation is better, because it helps fix #2656, and it also helps reduce the extent to which popup has to dabble in the navigation.

I ran the unit tests on this PR, and the unit test which previously failed, namely "going back from a dialog triggered from a dialog should result in the first dialog", did not fail with this fix.

gabrielschulhof added some commits Apr 18, 2012
@gabrielschulhof gabrielschulhof [navigation] Keep urlHistory in sync with browser history even when m…
…oving to/from a #&ui-state=dialog link via Back/Forward buttons
851fad0
@gabrielschulhof gabrielschulhof [navigation] Do not change hash nor add history entry when displaying…
… a dialog at a history entry that already has dialogHashKey -- Fixes: #2656
358f7de
@gseguin gseguin merged commit c6ef3af into jquery:master Apr 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment