[Webkit-unassigned] [Bug 33691] Drag and Drop source/destination code needs cleanup

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=33691





--- Comment #2 from Adam Roben (aroben) <aroben at apple.com>  2010-01-14 15:10:18 PST ---
(From update of attachment 46611)
> -static DragOperation defaultOperationForDrag(DragOperation srcOpMask)
> -{
> -    // This is designed to match IE's operation fallback for the case where
> -    // the page calls preventDefault() in a drag event but doesn't set dropEffect.
> -    if (srcOpMask & DragOperationCopy)
> -         return DragOperationCopy;
> -    if (srcOpMask & DragOperationMove || srcOpMask & DragOperationGeneric)
> -        return DragOperationMove;
> -    if (srcOpMask & DragOperationLink)
> -        return DragOperationLink;
> -
> -    // FIXME: Does IE really return "generic" even if no operations were allowed by the source?
> -    return DragOperationGeneric;
> -}
> -
>  bool DragController::tryDHTMLDrag(DragData* dragData, DragOperation& operation)
>  {
>      ASSERT(dragData);
> @@ -517,10 +502,8 @@ bool DragController::tryDHTMLDrag(DragDa
>          return false;
>      }
>  
> -    if (!clipboard->destinationOperation(operation)) {
> -        // The element accepted but they didn't pick an operation, so we pick one (to match IE).
> -        operation = defaultOperationForDrag(srcOpMask);
> -    } else if (!(srcOpMask & operation)) {
> +    operation = clipboard->destinationOperation();
> +    if (!(srcOpMask & operation)) {
>          // The element picked an operation which is not supported by the source
>          operation = DragOperationNone;
>      }

Is it really OK to make this change? Will we break websites that call
preventDefault() but don't set dropEffect?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.