Open Bug 1059382 Opened 6 years ago Updated 5 years ago
History API bug -- window
.history .state should not fire popstate after load .
Ugh. I meant that it is expected that the onpopstate event is NOT FIRED, but the actual is that it IS... can anyone edit the text above?
Component: Untriaged → Document Navigation
Product: Firefox → Core
> Chrome, Firefox, and IE11 all have this bug where the word "last" is confused for > "latest". It's very possible that the spec simply got changed after they all implemented it... or that it was agreed to be changed and wasn't. There have been a bunch of flip-flops in the spec about when popstate should or should not fire, and it's not clear to me whether the current text reflects the last thing that was agreed on...
If the spec was changed, it was definitely for the better as the current implementation, where a "trick-move" creates unexpected behavior, is not really optimal.
Is it at all possible for anyone to edit the initial text to say that the expected results are that the onpopstate event is not fired? I feel I might have to do-over here as it could be too confusing. :\
Bug comments aren't editable.
I believe we did several rounds of fixing the spec. So it did indeed change over time. It makes me very sad if the final spec was still not getting this stuff right. The proper behavior should be that popstate should only fire when transitioning between two session-history entries that use the same Document. Any time that the user presses back/forward and we switch Document, that should never fire popstate. So popstate is an event for indicating session-history traversal within a Document. pageshow/pagehide (as well as load/unload) are events for indication session-history traversal across Documents. But there's lots of complex edge cases. The code in comment 0 triggers one of them. It appears to be mutating the session-history entry while we are still loading that entry. But I agree that I would not expect popstate to fire there. Also adding Olli here since he's a docshell peer where all of this code lives.
Thank you. I indeed cannot reproduce the bug if I add a delay to the thing -- I think.
Should I open a new bug for https://www.w3.org/Bugs/Public/show_bug.cgi?id=27188#c13 ?
I went ahead and filed https://bugzilla.mozilla.org/show_bug.cgi?id=1185420. There seem to be a cluster of (probably related) issues affecting Firefox in that case.
You need to log in before you can comment on or make changes to this bug.