Bug 20565 - Drag and drop issues after DOM modifications
Summary: Drag and drop issues after DOM modifications
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 525.x (Safari 3.1)
Hardware: PC Windows Vista
: P1 Critical
Assignee: Nobody
URL: http://skypher.com/SkyLined/Repro/Saf...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2008-08-29 01:26 PDT by Berend-Jan Wever
Modified: 2010-04-19 11:34 PDT (History)
2 users (show)

See Also:


Attachments
Patch to use m_documentUnderMouse instead of element->ownerDocument() when element is NULL. (1.38 KB, patch)
2009-07-25 16:42 PDT, Aaron Golden
oliver: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Berend-Jan Wever 2008-08-29 01:26:47 PDT
The repro files for bug 20540 and bug 19516 no longer crash Safari with nightly when they are loaded but if either one of the repro's is drag-and-drop-ed into Safari twice, the second drag-and-drop causes a NULL pointer crash.

(f6c.df0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
WebKit!WebCore::DragController::concludeDrag+0x3a:
00000000`6d4a0cda 8b03            mov     eax,dword ptr [ebx]
ds:002b:00000000`00000000=????????
Comment 1 David Kilzer (:ddkilzer) 2009-07-20 14:12:35 PDT
<rdar://problem/7075690>
Comment 2 Aaron Golden 2009-07-25 16:42:16 PDT
Created attachment 33498 [details]
Patch to use m_documentUnderMouse instead of element->ownerDocument() when element is NULL.

This patch prevents the crash by avoiding using a NULL result from elementFromPoint.  I'm not sure if this is what we want or if we should, instead, prevent elementFromPoint from ever returning NULL in the first place.
Comment 3 Oliver Hunt 2009-07-29 18:04:40 PDT
Comment on attachment 33498 [details]
Patch to use m_documentUnderMouse instead of element->ownerDocument() when element is NULL.

This is basically a good patch but it needs a testcase, and i think there should be an assertion:
> +    if (element) {
           ASSERT(element->ownerDocument() == m_documentUnderMouse);
> +        innerFrame = element->ownerDocument()->frame();
> +    } else
> +        innerFrame = m_documentUnderMouse->frame();
> +    
>      ASSERT(innerFrame);
>  
>      if (dragData->containsColor()) {
Comment 4 Aaron Golden 2009-07-29 19:22:45 PDT
I can add the test case, but I'm confused by the assertion.

If element->ownerDocument() == m_documentUnderMouse then it seems like we should just use m_documentUnderMouse and not even bother getting the element.  Is that right?
Comment 5 Oliver Hunt 2010-01-13 23:13:20 PST
(In reply to comment #4)
> I can add the test case, but I'm confused by the assertion.
> 
> If element->ownerDocument() == m_documentUnderMouse then it seems like we
> should just use m_documentUnderMouse and not even bother getting the element. 
> Is that right?

Actually i think that assertion would be incorrect, but likewise i think m_documentUnderMouse would be wrong, take the following:

1. I start to drag content over an element
2. page load occurs, resulting in a new document
3. i drop

now the issue will be the m_documentUnderMouse will be bogus, and i think that's actually the underlying problem.
Comment 6 Berend-Jan Wever 2010-04-19 11:34:54 PDT
Seems to have been fixed at some point for it no longer reproduces.