Bug 9952 – REGRESSION: Repro crash when dragging an image from the window to the address bar

• Component: Page Loading
• Status: RESOLVED FIXED

To reproduce:
1. Go to the URL. Wait for it to finish loading.
2. Drag the image of Dr. Hibbert from the page into the address bar (notice that sometimes the cursor does not change to the "copy" cursor when over the address bar).
3. Click in the window.

Actual results:
Safari crashes or asserts in step 2, or doesn't display the image, then crashes in step 3.

Backtrace:

#0  0x01cb0b0c in WebCore::RenderObject::document (this=0x0) at WebCore/rendering/RenderObject.h:333
#1  0x01a496dc in WebCore::RenderObject::view (this=0x0) at WebCore/rendering/RenderObject.cpp:2275
#2  0x01972790 in -[WebCoreFrameBridge drawRect:] (self=0x19971260, _cmd=0x90a8f4a0, rect={origin = {x = 0, y = 0}, size = {width = 985, height = 840}}) at WebCore/bridge/mac/WebCoreFrameBridge.mm:905
#3  0x003714dc in -[WebHTMLView drawSingleRect:] (self=0x19c35f10, _cmd=0x406538, rect={origin = {x = 0, y = 0}, size = {width = 985, height = 840}}) at WebKit/WebView/WebHTMLView.m:2572
#4  0x0037190c in -[WebHTMLView drawRect:] (self=0x19c35f10, _cmd=0x90a8f4a0, rect={origin = {x = 0, y = 0}, size = {width = 985, height = 840}}) at WebKit/WebView/WebHTMLView.m:2623
#5  0x93734858 in -[NSView _drawRect:clip:] ()
#6  0x93733e18 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#7  0x00366508 in -[WebHTMLView(WebPrivate) _recursiveDisplayAllDirtyWithLockFocus:visRect:] (self=0x19c35f10, _cmd=0x90a6fea8, needsLockFocus=1 '\001', visRect={origin = {x = 0, y = 0}, size = {width = 985, height = 840}}) at WebKit/WebView/WebHTMLView.m:877
#8  0x93736b60 in _recursiveDisplayInRect2 ()
#9  0x907eb3c4 in CFArrayApplyFunction ()
#10 0x93733f2c in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#11 0x93736b60 in _recursiveDisplayInRect2 ()
#12 0x907eb3c4 in CFArrayApplyFunction ()
#13 0x93733f2c in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
#14 0x937333e0 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#15 0x937339a8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#16 0x937339a8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#17 0x937339a8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#18 0x937339a8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#19 0x937339a8 in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#20 0x93754044 in -[NSThemeFrame _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] ()
#21 0x9372d054 in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] ()
#22 0x93722348 in -[NSView displayIfNeeded] ()
#23 0x937221b8 in -[NSWindow displayIfNeeded] ()
#24 0x0001a5f8 in ?? ()
#25 0x93722064 in _handleWindowNeedsDisplay ()
#26 0x907db73c in __CFRunLoopDoObservers ()
#27 0x907db9dc in __CFRunLoopRun ()
#28 0x907db47c in CFRunLoopRunSpecific ()
#29 0x931eb740 in RunCurrentEventLoopInMode ()
#30 0x931ead4c in ReceiveNextEventCommon ()
#31 0x931eac40 in BlockUntilNextEventMatchingListInMode ()
#32 0x936eeae4 in _DPSNextEvent ()
#33 0x936ee7a8 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#34 0x00006740 in ?? ()
#35 0x936eacec in -[NSApplication run] ()
#36 0x937db87c in NSApplicationMain ()
#37 0x0005c77c in ?? ()
#38 0x0005c624 in ?? ()

[David Kilzer (:ddkilzer)]

Is this a regression from Bug 9466?

(In reply to comment #1)
> Is this a regression from Bug 9466?
> 

Just prior to fixing bug 9466 it was obviously impossible to reproduce this bug, but I think fixing bug 9466 just lifted the mask from this one, which was caused earlier (perhaps by the same change that cause bug 9466?).

[Darin Adler]

Created attachment 9539 [details]
reduction

[Darin Adler]

Created attachment 9540 [details]
file needed to use reduction (put this next to it on the local disk)

[Darin Adler]

Very simple reduction -- I predict this will be easy to fix.

Here's what I've found out so far. The problem happens because the image document is detached. The detach happens in the ~FrameView destructor (which contains this comment: "FIXME: Is this really the right place to call detach on the document?"). The FrameView in question has the same Frame as the FrameView that is coming in (Frame::setView() does not update the back pointer from the FrameView to the Frame), and hence the same document. The Iframe in the reduction serves the sole purpose of not allowing the page to go into the page cache, thus leading to the FrameView being deref'ed (and destructed) at that particular point.

I think the fix should be along the lines of addressing the FIXME, but it's also possible that there's some way to manage the pointers from FrameViews to Frame to avoid the detach.

[Alice Liu]

<rdar://problem/4680476>

I just found out that essentially the same crash can be reproduced in shipping Safari by clicking a link to about:blank with the back/forward cache disabled. To reproduce, go to
data:text/html,<a%20href="about:blank">Turn%20off%20the%20Back/Forward%20cache%20and%20click%20me</a>
then in Safari's Debug menu deselect Use Back/Forward Cache and click the link. The image case is a regression because of the new image document implementation.

manual-tests/form-value-restore.html fails because of this bug.

Created attachment 12536 [details]
Patch, including change log

This patch makes sure that the view does not mess with the frame when it is not its active view. No layout test regressions.

[Darin Adler]

Comment on attachment 12536 [details]
Patch, including change log

r=me!

[Mark Rowe (bdash)]

Landed in r18965.