This is behaving as designed. See the discussion on https://bugs.webkit.org/show_bug.cgi?id=41372, and the change to the HTML5 spec that was made: http://html5.org/tools/web-apps-tracker?from=5345&to=5346. Firing popstate after onload is as designed.

I'm not sure why Hixie said this was an implementation bug, since his first sentence makes it clear that popstate should be fired as part of navigation: "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."

I was wrong.

Thanks for clarifying!

Thank you very much for the lightning-fast clarification!

It would be useful to put together a best-practices code pattern for the onpopstate handler. Is there a preferred method for a script to distinguish between the initial onpopstate firing with a null state and a subsquent firing with a null state? It seems to me the first call with null state should be ignored (since the page has just been loaded) while later null states may require reloading or re-rendering of the page in order to recover the initial content associated with that URL.

mozilla firefox developer said this is a bug

https://bugzilla.mozilla.org/show_bug.cgi?id=658157
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12707

Yes, there was a meeting with Mozilla and a spec-change in March. Mozilla implemented these changes (http://hacks.mozilla.org/2011/03/history-api-changes-in-firefox-4/), Chrome/WebKit has not yet. Re-purposing this bug for that.

 Issue 87522  has been merged into this issue.

//found fast workaround to get same behawior as ff4:

setTimeout(function(){
	window.onpopstate = function(event){
		window.console && window.console.log(event);
	};
},1000);

Removing milestone on all bugs marked available and targeted at m17.  Please re-triage to a new milestone if desired.

This was mentioned again recently in http://dropshado.ws/post/15251622664/ignore-initial-popstate .  Who's a good owner for this?

https://bugs.webkit.org/show_bug.cgi?id=70876

https://bugs.webkit.org/show_bug.cgi?id=76035
http://trac.webkit.org/changeset/105308

http://trac.webkit.org/changeset/106077

https://bugs.webkit.org/show_bug.cgi?id=76035
http://trac.webkit.org/changeset/107058

please don't fire onpopstate after load like firefox
I think onpopstate must be one-to-one with every pushState

There are 2 bugs here. history.state is implemented. We can make that as fixed.
onpopstate firing on page load should be moved to a new issue.

Any update?
The popstate event emitted on load is really annoying.

Here is my workaround if it can helps someone:
https://gist.github.com/3551566

The latest W3C Candidate Recommendation (http://www.w3.org/TR/2012/CR-html5-20121217/browsers.html#history-traversal) makes it relatively clear that his is indeed a bug.


To paraphrase, "Fire a popstate event at the Window object of the Document if the Document of the specified entry has a latest entry, and that entry is not the specified entry."

Note that that spec is way out of date and has numerous problems. I would recommend http://whatwg.org/html instead.

Thanks. http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#history-traversal says pretty much the same though.

I've being trying to avoid this (as comment 11: https://code.google.com/p/chromium/issues/detail?id=63040#c11) and I guess this way behaves a little faster:

$(window).on('load', function () {
  setTimeout(function () {
    $(window).bind("popstate", function (event) {
      // Do whatever you want...
    });
  }, 0);
});

Binding the popstate event after the window loads works for me even with no delay.

Does popstate fired when user pressing on Back button and before browser navigate to previous page (user can listen this event and stop the navigation process of back button, like disable back button)? According to w3c:

onpopstate : Script to be run when the window's history changes

So, I though when pressing on Back button the history object invoked back() function which navigate to previous state on history object => that fired the popstate event.
Currently, Chrome fire popstate after window load success.

Not firing a popstate event is still a bug many months later. Any updates? 

The only workarounds are really kludgey involving timeouts or assuming things about history.state...

Please fix this! While Chrome's behavior did indeed match W3C specs circa 2010, the HTML5 spec was fixed in 2011 knocking Chrome out of compliance. If that's not incentive enough to do the right thing, even Microsoft (i.e., IE10) gets this behavior correct;)

Please fix this.

when is this going to be fixed? 

FYI, it is easy to fix this yourself if you have some sort of page state counter. For example:

window.onpopstate = function (evt) {
 var new_state = evt.state // evt.state can't be modified.
 if (typeof gs.page_state == "undefined") gs.page_state = null
 if ((gs.page_state == null) && (new_state == null)) return // Fix for browsers that pop the state on page load.
 set_page_state (new_state, true)
}

Please fix this old and very irritating bug.

There is no 100% reliable workaround.

CL=https://codereview.chromium.org/136463002/

We're tired of workarounds, please fix this.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=165221

------------------------------------------------------------------------
r165221 | jl@opera.com | 2014-01-16T13:53:34.787797Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/pushstate-object-types.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/pushstate-then-replacestate.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/replacestate-then-pushstate.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/popstate-after-load-complete-window-attribute.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/popstate-after-load-complete-body-inline-attribute.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/history/same-document-iframes-changing-pushstate-expected.txt?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/history/popstate-fires-with-pending-requests.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/navigation/redirect-on-back-updates-history-item-expected.txt?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/pushstate-with-fragment-urls-and-hashchange.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/document-destroyed-navigate-back.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/frame/DOMWindow.cpp?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/navigation/redirect-on-reload-updates-history-item-expected.txt?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/history/same-document-iframes-changing-fragment-expected.txt?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/popstate-after-load-complete-body-attribute.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/document-destroyed-navigate-back-with-fragment-scroll.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/popstate-after-load-complete-addeventlistener.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/resources/pushstate-in-iframe-child.html?r1=165221&r2=165220&pathrev=165221
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/loader/stateobjects/resources/replacestate-in-iframe-window-child.html?r1=165221&r2=165220&pathrev=165221

Don't fire popstate event on initial document load

According to the specification [1], a popstate event should only be fired
when the document has a "last entry" and the entry being navigated to isn't
it.  A document is created without a "last entry" and gets one just after
this check when it is first navigated to, so a popstate should be fired any
time a document is navigated to except for the first time after it has been
created.

[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#traverse-the-history (step 12-14 in particular)

BUG= 63040 

Review URL: https://codereview.chromium.org/136463002
------------------------------------------------------------------------

Still not landed on Chrome 32 stable, fixed on Chrome Canary 34.

Oh god thank you very much.

This is a good change, but it breaks our Chrome-only page (PNaCl demos -- https://gonativeclient.appspot.com/demo) which were relying on a null popstate event firing. Is it possible to make it more clear to a web developer of this behavior change?

!!!This bug is not fixed!!! The patch still misinterprets the text of the specification.

#45
'According to the specification [1], a popstate event should only be fired
when the document has a "last entry" and the entry being navigated to isn't
it.  A document is created without a "last entry" and gets one just after
this check when it is first navigated to, so a popstate should be fired any
time a document is navigated to except for the first time after it has been
created.'

'[1] http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#traverse-the-history (step 12-14 in particular)'

1) The document being navigated to is called the "specified entry".
2) The document being navigated from is called the "latest entry".
3) Steps 12-14 discuss the "specified entry" and the "latest entry".. not the LAST ENTRY! Latest entry, not last entry. BIG DIFFERENCE HERE my friend!!!

From http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#traverse-the-history:
"12) Let state changed be true if the Document of the specified entry has a latest entry, and that entry is not the specified entry; otherwise let it be false."
The "state changed" is true, because the latest entry is not the specified entry. This is where the logic of the patch diverges, because the patch considers the latest entry to be the "LAST" entry.

Examine the code below. Going to e.g. google.com, then the page with the code below, then back to google.com and back again to this page, should NOT FIRE ONPOPSTATE!

<!DOCTYPE html>
<html lang="en">
 <head>
 </head>
 <body>
  <script type="text/javascript">
   var history_control = new history_control_object ()
   function history_control_object (new_state) {
    window.addEventListener ('popstate', function (evt) {console.log (evt.state)})
    history.replaceState ({url: 'apple'}, "")
   }
  </script>
 </body>
</html>