Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Why do we jump across a refresh barrier when we refresh during a dialog/popup? #5065
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:
which is immediate corrected by pushState to
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.
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.
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
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.