Skip to content
This repository

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

Closed
gabrielschulhof opened this Issue September 18, 2012 · 7 comments

1 participant

Gabriel "_|Nix|_" Schulhof
Gabriel "_|Nix|_" Schulhof
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
Gabriel "_|Nix|_" Schulhof
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.

Gabriel "_|Nix|_" Schulhof
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 ...

Gabriel "_|Nix|_" Schulhof
Collaborator

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

Gabriel "_|Nix|_" Schulhof
Collaborator

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

Gabriel "_|Nix|_" Schulhof
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() ...

Gabriel "_|Nix|_" Schulhof
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 ...

Gabriel "_|Nix|_" Schulhof
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.

Gabriel "_|Nix|_" Schulhof gabrielschulhof closed this issue from a commit September 18, 2012
Gabriel "_|Nix|_" Schulhof [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
Gabriel "_|Nix|_" Schulhof gabrielschulhof closed this in 6ef910d September 18, 2012
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.