Summary: | HistoryItems with null CachedPages should never be left in the list of items; causes crash | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Beth Dakin <bdakin> | ||||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | bdakin, beidson, commit-queue, simon.fraser, thorton, zalan | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | Other | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Attachments: |
|
Description
Beth Dakin
2015-08-20 12:34:27 PDT
Created attachment 259486 [details]
Patch
Created attachment 259505 [details]
Patch
It turns out that fix did not work, so here is a new patch that does work.
Comment on attachment 259505 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=259505&action=review > Source/WebCore/page/FrameView.cpp:277 > I hope that none of the setHas*Scrollbar() calls (few lines below) trigger similar layout. (In reply to comment #3) > Comment on attachment 259505 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=259505&action=review > > > Source/WebCore/page/FrameView.cpp:277 > > > > I hope that none of the setHas*Scrollbar() calls (few lines below) trigger > similar layout. From what I can tell, they do not, but this is a great example of why this fix is hack-ish. http://trac.webkit.org/changeset/188712 Thanks Zalan! Re-opened since this is blocked by bug 148274 Rolled out in http://trac.webkit.org/changeset/188723 Re-naming the bug to reflect my new approach for a crash fix, Created attachment 259586 [details]
Patch
Here's another go.
Comment on attachment 259586 [details]
Patch
This seems pretty risky.
I wonder if the earlier patch broke everything because frame().view() is null normally, meaning frame().view() == this is never true? (In reply to comment #10) > Comment on attachment 259586 [details] > Patch > > This seems pretty risky. Can you elaborate? I think it seems extremely safe. Safer than limiting calls to resetScrollbars() from the FrameView destructor now that I have a better understanding of those implications. Comment on attachment 259586 [details]
Patch
I think this is fine, as long as all the layout tests actually run and don't crash :)
Thanks Brady! I ran WK1 and WK2 tests locally, and everything seems good. http://trac.webkit.org/changeset/188765 I think it would be good to land a layout test for this, if we can make one. |