Bug 112079 – Don't allow drags to start after a mouse press that creates a context menu

• Status: RESOLVED
• Resolution: FIXED
• Component: UI Events

[Daniel Cheng]

I did some some code archaeology. In EventHandler::sendContextMenuEvent(), we have this snippet:
2859	    // Clear mouse press state to avoid initiating a drag while context menu is up.
2860	    m_mousePressed = false;

However, in EventHandler::handleMouseDraggedEvent(), we have:
706	bool EventHandler::handleMouseDraggedEvent(const MouseEventWithHitTestResults& event)
707	{
708	    if (handleDrag(event, ShouldCheckDragHysteresis))
709	        return true;
710	
711	    if (!m_mousePressed)
712	        return false;

It's not entirely clear to me why the code in handleMouseDraggedEvent() is currently ordered this way, since the comment in sendContextMenuEvent() seems to indicate that this is supposed to prevent unintended interactions with dragging. However, this causes problems for the Chromium port on Linux (http://crbug.com/157134):

The problem is this:
1. User presses LMB and holds and starts selecting text.
2. User presses RMB which creates a context menu.
3. User release RMB above a context menu item to invoke it.
4. With LMB held, user continues moving the mouse cursor. This causes the renderer to eventually invoke Chromium's DragClientImpl::startDrag() method, which in turns, sets WebViewImpl::m_doingDragAndDrop to true. For whatever reason, the browser doesn't end up initiating a drag and drop on behalf of the renderer.

I've verified that flipping lines 708-709 and 711-712 fixes the issue; however, I'm also investigating why no drag is being initiated on the browser side.
This causes the renderer to ignore all input events and appear to be hung.

[Daniel Cheng]

Created attachment 194586 [details]
Patch

[Tony Chang]

Comment on attachment 194586 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=194586&action=review

> Source/WebCore/ChangeLog:13
> +        Covered by existing tests since it shouldn't change normal user-observable behavior.

It would be nice to make a manual test for this, if for no other reason than it would describe what should happen if you try to start a drag while a context menu is up.

[Daniel Cheng]

(In reply to comment #2)
> (From update of attachment 194586 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=194586&action=review
> 
> > Source/WebCore/ChangeLog:13
> > +        Covered by existing tests since it shouldn't change normal user-observable behavior.
> 
> It would be nice to make a manual test for this, if for no other reason than it would describe what should happen if you try to start a drag while a context menu is up.

Sure. I didn't include it initially because Chromium Win still doesn't behave quite the same as the other ports... however, this patch does make the behavior consistent across the Mac and Chromium Mac/Linux ports.

[Daniel Cheng]

Created attachment 194667 [details]
Patch

[Daniel Cheng]

Committed r146784: <http://trac.webkit.org/changeset/146784>

[Lucas Forschler]

Mass move bugs into the DOM component.