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

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

Comments

Projects
None yet
1 participant
@gabrielschulhof
Contributor

gabrielschulhof commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 18, 2012

Contributor

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.

Contributor

gabrielschulhof commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 18, 2012

Contributor

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

Contributor

gabrielschulhof commented Sep 18, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 18, 2012

Contributor

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

Contributor

gabrielschulhof commented Sep 18, 2012

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

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 18, 2012

Contributor

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

Contributor

gabrielschulhof commented Sep 18, 2012

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

@gabrielschulhof

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 18, 2012

Contributor

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

Contributor

gabrielschulhof commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 18, 2012

Contributor

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

Contributor

gabrielschulhof commented Sep 18, 2012

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

This comment has been minimized.

Show comment
Hide comment
@gabrielschulhof

gabrielschulhof Sep 18, 2012

Contributor

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.

Contributor

gabrielschulhof commented Sep 18, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment