WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
183372
Get rid of custom bindings for History's replaceState() / pushState()
https://bugs.webkit.org/show_bug.cgi?id=183372
Summary
Get rid of custom bindings for History's replaceState() / pushState()
Chris Dumez
Reported
2018-03-06 09:07:06 PST
Get rid of custom bindings for History IDL interface.
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
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Chris Dumez
Comment 1
2018-03-06 13:28:55 PST
Created
attachment 335133
[details]
Patch
Chris Dumez
Comment 2
2018-03-06 13:30:20 PST
Created
attachment 335134
[details]
Patch
Chris Dumez
Comment 3
2018-03-07 18:30:30 PST
Any takers?
youenn fablet
Comment 4
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?
Chris Dumez
Comment 5
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.
Chris Dumez
Comment 6
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.
WebKit Commit Bot
Comment 7
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
>
WebKit Commit Bot
Comment 8
2018-03-07 19:31:25 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 9
2018-03-07 19:32:17 PST
<
rdar://problem/38247484
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug