[chromium] Add support for history.pushState and history.replaceState

• Component: Page Loading
• Status: RESOLVED FIXED

[Darin Fisher (:fishd, Google)]

[chromium] Add support for history.pushState and history.replaceState

This involves making the changes required to support these methods in the
Chromium port.

[Darin Fisher (:fishd, Google)]

Created attachment 50758 [details]
v1 patch

[Darin Fisher (:fishd, Google)]

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 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)]

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)]

>  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)]

Landed as http://trac.webkit.org/changeset/56070

[Adam Barth]

> Right, but line breaking like this is optional, no?

Yes, it's optional.