Changeset 188712 in webkit
- Timestamp:
- Aug 20, 2015 3:37:22 PM (9 years ago)
- Location:
- trunk/Source/WebCore
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/WebCore/ChangeLog
r188711 r188712 1 2015-08-20 Beth Dakin <bdakin@apple.com> 2 3 WK1 can re-enter layout during FrameView destruction and crash 4 https://bugs.webkit.org/show_bug.cgi?id=148237 5 -and corresponding- 6 rdar://problem/22356782 7 8 Reviewed by Zalan Bujtas. 9 10 This is a safe fix for the time being. We won't resetScrollbars() for a FrameView 11 that is in the PageCache because resetting scrollbars can re-enter layout for the 12 Frame's new FrameView, which leads to updating pages in the page cache, which 13 leads to a crash because we're in the process of destroying something 14 in the page cache. We should not be able to get into this mess at all. 15 * page/FrameView.cpp: 16 (WebCore::FrameView::~FrameView): 17 1 18 2015-08-20 Chris Dumez <cdumez@apple.com> 2 19 -
trunk/Source/WebCore/page/FrameView.cpp
r188659 r188712 268 268 269 269 removeFromAXObjectCache(); 270 resetScrollbars(); 270 271 // FIXME: This is a safe fix for rdar://problem/22356782. We won't resetScrollbars() for a FrameView that is in 272 // the PageCache because resetting scrollbars can re-enter layout for the Frame's new FrameView, which leads to 273 // updating pages in the page cache, which leads to a crash because we're in the process of destroying something 274 // in the page cache. We should not be able to get into this mess at all. 275 if (frame().view() == this) 276 resetScrollbars(); 271 277 272 278 // Custom scrollbars should already be destroyed at this point
Note: See TracChangeset
for help on using the changeset viewer.