RESOLVED FIXED 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 Tuesday, March 16, 2010 5:04:39 AM UTC
[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 Tuesday, March 16, 2010 5:27:00 AM UTC
Created attachment 50758 [details] v1 patch
Darin Fisher (:fishd, Google)
Comment 2 Tuesday, March 16, 2010 5:30:22 AM UTC
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 Tuesday, March 16, 2010 8:12:09 AM UTC
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 Tuesday, March 16, 2010 6:13:06 PM UTC
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 Tuesday, March 16, 2010 6:25:15 PM UTC
> 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 Tuesday, March 16, 2010 6:27:25 PM UTC
Adam Barth
Comment 7 Tuesday, March 16, 2010 7:05:13 PM UTC
> 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.