[Webkit-unassigned] [Bug 43152] New: Assertion failure in FrameView::layout when modifying the DOM during pagehide with PageCache enabled
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Jul 28 15:19:11 PDT 2010
https://bugs.webkit.org/show_bug.cgi?id=43152
Summary: Assertion failure in FrameView::layout when modifying
the DOM during pagehide with PageCache enabled
Product: WebKit
Version: 528+ (Nightly build)
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: Normal
Priority: P2
Component: Page Loading
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: mihaip at chromium.org
CC: darin at apple.com, bdakin at apple.com
Created an attachment (id=62885)
--> (https://bugs.webkit.org/attachment.cgi?id=62885)
Test case
The attached test case triggers this assertion failure in debug builds:
ASSERTION FAILED: m_frame->view() == this
(/Users/mihaip/Developer/source/webkit1/WebCore/page/FrameView.cpp:634 void WebCore::FrameView::layout(bool))
0 com.apple.WebCore 0x00000001017fd345 WebCore::FrameView::layout(bool) + 449 (FrameView.cpp:634)
1 com.apple.WebCore 0x00000001017fe5ea WebCore::FrameView::layoutTimerFired(WebCore::Timer<WebCore::FrameView>*) + 30 (FrameView.cpp:1332)
2 com.apple.WebCore 0x0000000101801753 WebCore::Timer<WebCore::FrameView>::fired() + 113 (Timer.h:98)
3 com.apple.WebCore 0x000000010202ce68 WebCore::ThreadTimers::sharedTimerFiredInternal() + 208 (ThreadTimers.cpp:115)
4 com.apple.WebCore 0x000000010202cff7 WebCore::ThreadTimers::sharedTimerFired() + 25 (ThreadTimers.cpp:91)
5 com.apple.WebCore 0x0000000101efefd4 WebCore::timerFired(__CFRunLoopTimer*, void*) + 73 (SharedTimerMac.mm:87)
6 com.apple.CoreFoundation 0x00007fff83b67678 __CFRunLoopRun + 6488
7 com.apple.CoreFoundation 0x00007fff83b6584f CFRunLoopRunSpecific + 575
8 com.apple.HIToolbox 0x00007fff830e991a RunCurrentEventLoopInMode + 333
9 com.apple.HIToolbox 0x00007fff830e971f ReceiveNextEventCommon + 310
10 com.apple.HIToolbox 0x00007fff830e95d8 BlockUntilNextEventMatchingListInMode + 59
11 com.apple.AppKit 0x00007fff8451e29e _DPSNextEvent + 708
12 com.apple.AppKit 0x00007fff8451dbed -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
13 com.apple.Safari 0x0000000100015c96 0x100000000 + 89238
14 com.apple.AppKit 0x00007fff844e38d3 -[NSApplication run] + 395
15 com.apple.AppKit 0x00007fff844dc5f8 NSApplicationMain + 364
16 com.apple.Safari 0x0000000100009b18 0x100000000 + 39704
The triggering conditions appear to be 1) the DOM being modified in the pagehide handler 2) the page cache being enabled (adding an unload event handler to disable results in this not crashing). The fact that it's a data: URL does not seem to matter, the crash also happens when changing the location to a regular URL.
There is this comment and check in FrameView.cpp immediately after the assert:
// This early return should be removed when rdar://5598072 is resolved. In the meantime, there is a
// gigantic CrashTracer because of this issue, and the early return will hopefully cause graceful
// failure instead.
if (m_frame->view() != this)
return;
That was added in http://trac.webkit.org/changeset/29878. Cc-ing Darin and Beth in case there's anything relevant to this bug at the rdar:// URL.
Bug 32752 may be related, since it's the same assert and it happens on a page transition, but I can't reproduce it. Bug 19564 also mentions this assert, and says that HTMLFrameElement09.xhtml fails because of it (and it's still disabled as of http://trac.webkit.org/changeset/34803), but I can't reproduce the assert when running it locally (though the test doesn't pass).
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list