[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