| Issue 63040: | Add window.history.state and don't fire popstate after load | |
| 26 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Chrome Version : Google Chrome 7.0.517.44 (Official Build 64615) WebKit 534.7 URLs (if applicable) :http://www.splefty.com/js/popstate.html Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: OK Firefox 3.x: not tested IE 7/8: onpopstate not supported What steps will reproduce the problem? 1. Go to URL above. You should not get a alert box, but you will because Chrome is throwing an onpopstate event on page load. It should only be thrown on a history action (forward / back buttons) What is the expected result? I believe it should do nothing. Review the W3C editors acerbic response in ticket 10365 below and see if you agree. What happens instead? In the latest build of Chrome, onpopstate fires on initial navigation to the page.. This much is clear. Please provide any additional information below. Attach a screenshot if possible. See also http://www.google.com/support/forum/p/Chrome/thread?tid=34fd0582af7d5584&hl=en See also W3C: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10365 Relevant quote from ticket 10365: "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."
,
Nov 13, 2010
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."
Status: WontFix
Cc: ian.hickson mih...@chromium.org
,
Nov 13, 2010
I was wrong.
,
Nov 13, 2010
Thanks for clarifying!
,
Nov 15, 2010
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.
,
May 26, 2011
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
,
May 27, 2011
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.
Summary: Add window.history.state and don't fire popstate after load
Status: Assigned Owner: mihaip@chromium.org Labels: Mstone-14
,
Jul 26, 2011
(No comment was entered for this change.)
Labels: -Mstone-14 Mstone-15
,
Aug 30, 2011
Issue 87522 has been merged into this issue.
Cc: anan...@chromium.org vivi...@chromium.org
,
Aug 31, 2011
(No comment was entered for this change.)
Labels: -Mstone-15 Mstone-16
,
Sep 5, 2011
//found fast workaround to get same behawior as ff4:
setTimeout(function(){
window.onpopstate = function(event){
window.console && window.console.log(event);
};
},1000);
,
Oct 24, 2011
(No comment was entered for this change.)
Labels: -Mstone-16 MovedFrom-16 Mstone-17
,
Oct 26, 2011
(No comment was entered for this change.)
Status: Available
Owner: --- Labels: WebKit-ID-70876
,
Nov 2, 2011
(No comment was entered for this change.)
Labels: -WebKit-ID-70876 WebKit-ID-70876-NEW
,
Dec 19, 2011
Removing milestone on all bugs marked available and targeted at m17. Please re-triage to a new milestone if desired.
Labels: -Mstone-17 MovedFrom-17
,
Jan 5, 2012
This was mentioned again recently in http://dropshado.ws/post/15251622664/ignore-initial-popstate . Who's a good owner for this?
,
Jan 20, 2012
https://bugs.webkit.org/show_bug.cgi?id=70876
Labels: -WebKit-ID-70876-NEW WebKit-ID-70876-RESOLVED
,
Jan 20, 2012
(No comment was entered for this change.)
Labels: -WebKit-ID-70876-RESOLVED WebKit-ID-76035
,
Jan 20, 2012
https://bugs.webkit.org/show_bug.cgi?id=76035 http://trac.webkit.org/changeset/105308
Labels: -WebKit-ID-76035 WebKit-ID-76035-UNCONFIRMED WebKit-Rev-105308
,
Feb 8, 2012
https://bugs.webkit.org/show_bug.cgi?id=76035 http://trac.webkit.org/changeset/107058
Labels: -WebKit-ID-76035-UNCONFIRMED WebKit-ID-76035-RESOLVED WebKit-Rev-107058
,
May 2, 2012
please don't fire onpopstate after load like firefox I think onpopstate must be one-to-one with every pushState |
||||||||
| ► Sign in to add a comment | |||||||||
Cc: da...@chromium.org
Labels: -Area-Undefined Area-WebKit WebKit-JavaScript