Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
gabrielschulhof opened this Issue · 7 comments

1 participant

@gabrielschulhof
Collaborator

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
@gabrielschulhof
Collaborator

Observation:

  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.

@gabrielschulhof
Collaborator

@johnbender

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 ...

@gabrielschulhof
Collaborator

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

@gabrielschulhof
Collaborator

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

@gabrielschulhof
Collaborator

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() ...

@gabrielschulhof
Collaborator

... 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 ...

@gabrielschulhof
Collaborator

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 closed this issue from a commit
@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
6ef910d
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.