RESOLVED FIXED Bug 36152
[chromium] Add support for history.pushState and history.replaceState
https://bugs.webkit.org/show_bug.cgi?id=36152
Summary [chromium] Add support for history.pushState and history.replaceState
Darin Fisher (:fishd, Google)
Reported 2010-03-15 21:04:39 PDT
[chromium] Add support for history.pushState and history.replaceState This involves making the changes required to support these methods in the Chromium port.
Attachments
v1 patch (20.74 KB, patch)
2010-03-15 21:27 PDT, Darin Fisher (:fishd, Google)
abarth: review+
Darin Fisher (:fishd, Google)
Comment 1 2010-03-15 21:27:00 PDT
Created attachment 50758 [details] v1 patch
Darin Fisher (:fishd, Google)
Comment 2 2010-03-15 21:30:22 PDT
With this patch, all stateobject layout tests pass except for: fast/loader/stateobjects/pushstate-object-types.html = TEXT fast/loader/stateobjects/state-api-on-detached-frame-crash.html = TEXT The first fails due to differences in the way we serialize Date and RegExp objects. The second fails due to an exception thrown--not a crash, which the test was written to detect--while trying to access window.history.replaceState on a detached window (from an iframe that has been removed).
Adam Barth
Comment 3 2010-03-16 00:12:09 PDT
Comment on attachment 50758 [details] v1 patch Ok. I'm sad about backForwardNavigationScheme, but it looks like that's already there... 590 bool isHashChange = 591 !m_webFrame->frame()->loader()->history()->currentItem()->stateObject(); No need to line break in WebKit-land.
Darin Fisher (:fishd, Google)
Comment 4 2010-03-16 10:13:06 PDT
Thanks Adam. Yes, backForwardNavigationScheme is the suck. This change makes it suck a bit less since it will be seen by much less code; however, I really need to kill it somehow. It should be pretty easy to do :)
Darin Fisher (:fishd, Google)
Comment 5 2010-03-16 10:25:15 PDT
> 590 bool isHashChange = > 591 > !m_webFrame->frame()->loader()->history()->currentItem()->stateObject(); > > No need to line break in WebKit-land. Right, but line breaking like this is optional, no? There are a number of similar line breaks in the same function and in this file. I prefer to leave the line breaks for readability.
Darin Fisher (:fishd, Google)
Comment 6 2010-03-16 10:27:25 PDT
Adam Barth
Comment 7 2010-03-16 11:05:13 PDT
> Right, but line breaking like this is optional, no? Yes, it's optional.
Note You need to log in before you can comment on or make changes to this bug.