Why do we jump across a refresh barrier when we refresh during a dialog/popup?

[gabrielschulhof]

The sequence:

page* -> popup -> refresh -> same popup <- back

At this point we are at *. IOW, we have jumped to the incarnation of jQM that was obliterated by the refresh.

This only happens with pushState turned on, for the following reason:

1. Let's assume the initial URL is http://domain/path/to/page.html
2. When we open the popup, the resulting URL is

http://domain/path/to/page.html#/path/to/page.html&ui-state=dialog

which is immediate corrected by pushState to

http://domain/path/to/page.html#&ui-state=dialog

1. We refresh, causing jQM to be reloaded. When it is reloaded, it behaves as if the initial URL had been

http://domain/path/to/page.html#&ui-state=dialog

This is correct, however, what the reloaded jQM doesn't know is that there's some pushstate associated with this history entry, because it seems pushstate is not cleared by a refresh. So, while jQM thinks the initial URL is http://domain/path/to/page.html#&ui-state=dialog, the real initial URL is http://domain/path/to/page.html#/path/to/page.html&ui-state=dialog.

1. When you open the popup the second time, the resulting URL is http://domain/path/to/page.html#/path/to/page.html&ui-state=dialog, because, while popup checks to make sure it doesn't recreate the initial hash, it is being told that the initial hash is "#&ui-state=dialog", and not "#/path/to/page.html&ui-state=dialog" which is what it wants to set, so it doesn't tack on an extra hash key to avoid reproducing the initial URL.

Now, since the real initial URL is exactly the same as that which results from popup's manipulations, no new history entry is created when the popup appears. Thus, when the popup closes, it goes back across the refresh barrier.

Thus, during init, we need to examine whether there is some popstate associated with the initial URL and try to recover the real URL that was cleaned up to result in this initial URL, and record its hash as the initial hash.

[gabrielschulhof]

This only happens in Chrome. FF12 behaves correctly.

So, perhaps it's a Chrome bug that the pushstate is not cleared upon refresh.

[gabrielschulhof]

Thus, during init, we need to examine whether there is some popstate associated with the initial URL and try to recover the real URL that was cleaned up to result in this initial URL, and record its hash as the initial hash.

Not sure how to accomplish that. The only way to obtain the state that was attached to the history entry is to grab it during popstate, but it seems that Chrome doesn't really give it to you during init. You get null. Also, if there was a way to retrieve the popstate of the initial URL, that popstate is not to be trusted, because it could be a malicious site that sets up the history entry, then refreshes itself loading jQM.

[gabrielschulhof]

This illustrates the problem using vanilla js.

[gabrielschulhof]

Another interesting thing seems to be happening. Even though we jump across the refresh barrier in Chrome, the state of the DOM is actually the one from before the refresh. Check out this jsbin.

Now, the fact remains that FF and Chrome handle history entry creation differently in this case. I'm not sure which one is correct.

[gabrielschulhof]

I have posted to chromium-dev asking whether this behaviour is a bug.

[arschmitz]

@gabrielschulhof is this still relevant? this is old and dialogs are gone? re open this if its still is. Closing