Skip to content
This repository
Browse code

[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
  • Loading branch information...
commit 6ef910d929edaa4c479eef61a814beb82b685c0f 1 parent 919a15d
Gabriel "_|Nix|_" Schulhof authored

Showing 1 changed file with 2 additions and 1 deletion. Show diff stats Hide diff stats

  1. 3  js/jquery.mobile.init.js
3  js/jquery.mobile.init.js
@@ -86,7 +86,8 @@ define( [ "jquery", "./jquery.mobile.core", "./jquery.mobile.support", "./jquery
86 86
 			if ( ! ( $.mobile.hashListeningEnabled &&
87 87
 				$.mobile.path.isHashValid( location.hash ) &&
88 88
 				( $( hashPage ).is( ':jqmData(role="page")' ) ||
89  
-					$.mobile.path.isPath( hash ) ) ) ) {
  89
+					$.mobile.path.isPath( hash ) ||
  90
+					hash === $.mobile.dialogHashKey ) ) ) {
90 91
 
91 92
 				// Store the initial destination
92 93
 				if ( $.mobile.path.isHashValid( location.hash ) ) {

2 notes on commit 6ef910d

John Bender

@gabrielschulhof

Why does the framework need to trigger a hashchange here? Don't we want to load the first page when the initial hash is the dialog hash key?

Gabriel "_|Nix|_" Schulhof
Collaborator

It needs to trigger a hashchange so popstate information can be recorded for this case. The reason for that is that when you navigate to a dialog from a page with an initial URL that has a dialog hash key, when you go back from the dialog, a popstate event occurs, but no hashchange event occurs, because the cosmetically corrected URL for the dialog is the same as the initial URL. However, onPopState will call _handleHashChange manually so we can still handle this case as a normal hashchange. This is one of the reasons we came up with the "navigate" event. In brief:

  1. Go to http://jquerymobile.com/test/docs/pages/dialog/index.html#&ui-state=dialog
  2. Click on Open Dialog. This results in a URL of

http://jquerymobile.com/test/docs/pages/dialog/index.html#/test/docs/pages/dialog/index.html&ui-state=dialog

which is corrected in the pushstate plugin to

http://jquerymobile.com/test/docs/pages/dialog/index.html#&ui-state=dialog

Now, the dialog's history entry is identical to the initial URL's history entry.

So, when you close the dialog by going back you don't get a hashchange. Nevertheless, you get a popstate event. However, the popstate event only calls _handleHashChange if you've earlier saved some state[1]. Thus, we must make sure that an earlier state is saved. We do that in onHashChange, so we must ensure that onHashChange happens for the first page. Thus, we emit hashchange.

Please sign in to comment.
Something went wrong with that request. Please try again.