Skip to content

Navigation breakage when inital url contains a dialog hash key (and nothing else) #5021

gabrielschulhof opened this Issue Sep 18, 2012 · 7 comments

1 participant


I'm opening this issue to track the ongoing initial-hash-is-dialog-hash-key saga.

  1. It only happens when the URL is of the form http://domain/path/to/page.html#&ui-state=dialog
  2. It doesn't happen when $.mobile.pushStateEnabled = false


  1. Check out 14855ad.
  2. Replace js/jquery.js with jquery-1.6.4.js
  3. This issue appears.
  4. git clean -x -d -f -f
  5. Check out ee0b8ad.
  6. Replace js/jquery.js with jquery-1.6.4.js
  7. The issue does not appear.

Thus, 14855ad appears to have introduced this issue.



It seems that, because of 14855ad onPopState no longer calls _handleHashChange when returning from a dialog located at http://domain/path/to/page.html#&ui-state=dialog to an initial URL of the form http://domain/path/to/page.html#&ui-state=dialog ...


So, I think jQuery is off the hook on this one.


Aha! After that commit, onHashChange isn't getting called because of the initial URL!


OK, so, in initializePage, when the hash is "#&ui-state=dialog", the code needs to go to the branch that triggers hashchange, not to the branch that calls changePage() ...


... or not ... interestingly, the nav works correctly if the URL initially has #&ui-state=dialog&ui-state=dialog, even though initializePage doesn't trigger hashchange by hand ...


OK, so, in the case of #&ui-state=dialog&ui-state=dialog, the browser seems to "naturally" emit hashchange, whereas in the case of #&ui-state=dialog we were relying on onPopState() to call _handleHashChange, because the browser does not "naturally" emit hashchange when going from location x to location x.

The reason it was 14855ad that broke things and not some other commit is that before this commit, the hash was being passed as a selector to jQuery in the form of $( location.hash + ":jqmData(role='page')" ) and that selector was actually returning non-empty for $( "#&ui-state=dialog:jqmData(role='page')" )! This lead the code down the path of triggering a hashchange event!

So, the incorrect behaviour of the code prior to the above-mentioned commit was actually handling the initial #&ui-state=dialog case correctly, whereas the correct behaviour does not. Thus, we must add another special case for #&ui-state=dialog.

@gabrielschulhof gabrielschulhof added a commit that closed this issue Sep 18, 2012
@gabrielschulhof gabrielschulhof [init] When the hash portion of the initial URL is exactly equal to t…
…he dialog hash key, we must trigger a hashchange -- Fixes #5021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.