This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10365 - popstate event fires after onload (first page visit) -- intended behavior? would be annoying if there was a script that ajax loaded a page at onpopstate, and hand typing in a url, the page is returned by the server, and then onpopstate fires after onload,
Summary: popstate event fires after onload (first page visit) -- intended behavior? wo...
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-14 12:19 UTC by contributor
Modified: 2010-11-13 20:31 UTC (History)
4 users (show)

See Also:

Attachments
test for firing of popstate and onload (119 bytes, text/html)
2010-10-31 01:52 UTC, henry.fai.hang.chan 		Details

Description contributor 2010-08-14 12:19:57 UTC 
Section: http://www.whatwg.org/specs/web-apps/current-work/#event-popstate

Comment:
popstate event fires after onload (first page visit) -- intended behavior?
would be annoying if there was a script that ajax loaded a page at onpopstate,
and hand typing in a url, the page is returned by the server, and then
onpopstate fires after onload, and the browser/javascript requests the same
page again with ajax.  I think popstate should not fire after onload.  if a
script needs it then they should attach to both onpopstate and onload instead.

Posted from: 219.77.175.157
Comment 1 Ian 'Hixie' Hickson 2010-09-24 00:44:28 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: It only fires after onload if you've gone back or forward in the history.

Am I misunderstanding something here? The problem described doesn't seem to exist.
Comment 2 henry.fai.hang.chan 2010-10-31 01:52:20 UTC 
Firefox and chrome fires onpopstate after onload even without going back/forward.

Is this a spec error or implementation problem?

Should the spec clarify if a page load (just entering into location bar, no back/forward) counts as "navigating to a session history entry"?
Comment 3 henry.fai.hang.chan 2010-10-31 01:52:58 UTC 
Created attachment 930 [details]
test for firing of popstate and onload
Comment 4 Ian 'Hixie' Hickson 2010-11-03 07:47:11 UTC 
The spec seems completely unambiguous here  search for the string "fire a popstate event" for the only two occurrences, neither of which can happen without history traversal. Regarding the question in comment 2, a page load results in the "navigate" algorithm being invoked, which unambiguously results in history traversal.

Thus what you describe is an implementation bug.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: Not a spec bug.
Comment 5 Ian 'Hixie' Hickson 2010-11-13 20:31:35 UTC 
The comment in http://code.google.com/p/chromium/issues/detail?id=63040 is right, I made a mistake: popstate will fire after load with a 'null' state object, even without going back/forward. I missed that the state object is set to null if history traversal occurs without state (we changed that at some point).

This is as designed, though; the popstate event handler is expected to grab the appropriate data given the provided state object. It's easy to not grab data if the state is null.