Bug 183372 - Get rid of custom bindings for History's replaceState() / pushState()
Summary: Get rid of custom bindings for History's replaceState() / pushState()
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-03-06 09:07 PST by Chris Dumez
Modified: 2018-03-07 19:32 PST (History)
13 users (show)

See Also:


Attachments
Patch (10.04 KB, patch)
2018-03-06 13:28 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (10.31 KB, patch)
2018-03-06 13:30 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2018-03-06 09:07:06 PST
Get rid of custom bindings for History IDL interface.
Comment 1 Chris Dumez 2018-03-06 13:28:55 PST
Created attachment 335133 [details]
Patch
Comment 2 Chris Dumez 2018-03-06 13:30:20 PST
Created attachment 335134 [details]
Patch
Comment 3 Chris Dumez 2018-03-07 18:30:30 PST
Any takers?
Comment 4 youenn fablet 2018-03-07 18:58:11 PST
Comment on attachment 335134 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=335134&action=review

> Source/WebCore/page/History.cpp:175
> +    m_cachedState = { };

It is not clear to me that why we need to clear m_cachedState here.  Is it an optimization? Or is stateChanged() not be true?
Comment 5 Chris Dumez 2018-03-07 18:59:32 PST
(In reply to youenn fablet from comment #4)
> Comment on attachment 335134 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=335134&action=review
> 
> > Source/WebCore/page/History.cpp:175
> > +    m_cachedState = { };
> 
> It is not clear to me that why we need to clear m_cachedState here.  Is it
> an optimization? Or is stateChanged() not be true?

This is to maintain the previous behavior. There are tests expecting this behavior that would start failing otherwise.
Comment 6 Chris Dumez 2018-03-07 19:02:39 PST
(In reply to Chris Dumez from comment #5)
> (In reply to youenn fablet from comment #4)
> > Comment on attachment 335134 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=335134&action=review
> > 
> > > Source/WebCore/page/History.cpp:175
> > > +    m_cachedState = { };
> > 
> > It is not clear to me that why we need to clear m_cachedState here.  Is it
> > an optimization? Or is stateChanged() not be true?
> 
> This is to maintain the previous behavior. There are tests expecting this
> behavior that would start failing otherwise.

Iirc, the issue is that you can pushState then history.back(). If pushState did not blow up the cache, then history.state might return the same cached value from before the pushState. This is observable and tests expect we re-deserialize in such case even though stateChanged() would return false.
Comment 7 WebKit Commit Bot 2018-03-07 19:31:24 PST
Comment on attachment 335134 [details]
Patch

Clearing flags on attachment: 335134

Committed r229392: <https://trac.webkit.org/changeset/229392>
Comment 8 WebKit Commit Bot 2018-03-07 19:31:25 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Radar WebKit Bug Importer 2018-03-07 19:32:17 PST
<rdar://problem/38247484>