[Webkit-unassigned] [Bug 41372] New: popstate event is not fired until document opts in by calling pushstate.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Jun 29 14:13:08 PDT 2010
https://bugs.webkit.org/show_bug.cgi?id=41372
Summary: popstate event is not fired until document opts in by
calling pushstate.
Product: WebKit
Version: 528+ (Nightly build)
Platform: PC
URL: http://people.mozilla.org/~jlebar/test/webkit/popstate
-load.html
OS/Version: Linux
Status: UNCONFIRMED
Severity: Normal
Priority: P2
Component: Page Loading
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: justin.lebar+bug at gmail.com
STR:
* Open the JS console
* Visit http://people.mozilla.org/~jlebar/test/webkit/popstate-load.html
Expected results:
* Console displays "popstate".
Actual results:
* Console displays nothing.
Chrome 5.0.375.86 on Ubuntu 10.04.
It seems that the popstate event is not fired until the document opts in by calling pushstate. That is, if you visit the test page, click back, and then click forward, the page also doesn't get a popstate event. But if you click the pushstate button, then going back and forward always gives a popstate, even when you're going forward to the original page.
Step 10 in the history traversal algorithm [1] suggests that this is the wrong behavior. The line at [2] which says "the popstate event is fired when navigating to a session history entry that represents a state object" is, I think, misleading. I'll post to whatwg to see if we can get that changed.
[1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#history-traversal
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list