Re: Issue 63040 in chromium: Add window.history.state and don't fire popstate after load

[chro...@googlecode.com]

Updates:
Summary: Add window.history.state and don't fire popstate after load
Status: Assigned
Owner: mih...@chromium.org
Labels: Mstone-14

Comment #7 on issue 63040 by mih...@chromium.org: Add window.history.state
and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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.

[chro...@googlecode.com]

Comment #11 on issue 63040 by kaspars....@efumo.lv: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

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

[chro...@googlecode.com]

Updates:
Status: Available
Owner: ---
Labels: WebKit-ID-70876

Comment #13 on issue 63040 by mih...@chromium.org: Add window.history.state

and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Labels: -WebKit-ID-70876-RESOLVED WebKit-ID-76035

Comment #18 on issue 63040 by mih...@chromium.org: Add window.history.state

[chro...@googlecode.com]

Updates:
Labels: -WebKit-ID-76035 WebKit-ID-76035-UNCONFIRMED WebKit-Rev-105308

Comment #19 on issue 63040 by bugdro...@chromium.org: Add

window.history.state and don't fire popstate after load

http://code.google.com/p/chromium/issues/detail?id=63040#c19

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

[chro...@googlecode.com]

Updates:
Labels: -WebKit-ID-76035-UNCONFIRMED WebKit-ID-76035-RESOLVED
WebKit-Rev-107058

Comment #21 on issue 63040 by bugdro...@chromium.org: Add

window.history.state and don't fire popstate after load

http://code.google.com/p/chromium/issues/detail?id=63040#c21

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

[chro...@googlecode.com]

Comment #22 on issue 63040 by zhouyanm...@gmail.com: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #23 on issue 63040 by ericbide...@chromium.org: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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.

[chro...@googlecode.com]

Comment #24 on issue 63040 by sonny.pi...@gmail.com: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #25 on issue 63040 by sonny.pi...@gmail.com: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #26 on issue 63040 by sonny.pi...@gmail.com: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #27 on issue 63040 by ksh...@crct.de: Add window.history.state and

don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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."

[chro...@googlecode.com]

Comment #29 on issue 63040 by ksh...@crct.de: Add window.history.state and

don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #30 on issue 63040 by p2km...@gmail.com: Add window.history.state

and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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.

[chro...@googlecode.com]

Comment #32 on issue 63040 by tranquoc...@gmail.com: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

Does popstate fired when user pressing on 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.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #33 on issue 63040 by tranquoc...@gmail.com: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #36 on issue 63040 by i...@segment.io: Add window.history.state and

don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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...

[chro...@googlecode.com]

Comment #38 on issue 63040 by agamemnus: Add window.history.state and don't

fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

Please fix this.

[chro...@googlecode.com]

Comment #41 on issue 63040 by a...@zenexity.com: Add window.history.state

and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

Please fix this old and very irritating bug.

There is no 100% reliable workaround.

[chro...@googlecode.com]

Updates:
Status: Started
Owner: j...@opera.com

Comment #42 on issue 63040 by j...@opera.com: Add window.history.state and

don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #43 on issue 63040 by j...@opera.com: Add window.history.state and

don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #44 on issue 63040 by sim...@homeservealliance.com: Add

window.history.state and don't fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

We're tired of workarounds, please fix this.

[chro...@googlecode.com]

Comment #47 on issue 63040 by laukstein: Add window.history.state and don't

fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

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

[chro...@googlecode.com]

Comment #50 on issue 63040 by agamemnus: Add window.history.state and don't

fire popstate after load
http://code.google.com/p/chromium/issues/detail?id=63040

!!!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>