You can clone with
HTTPS or Subversion.
I'm opening this issue to track the ongoing initial-hash-is-dialog-hash-key saga.
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.
[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