Bug 214513

Summary: [UI Events] Make mousemove cancelable
Product: WebKit Reporter: zalan <zalan>
Component: UI EventsAssignee: zalan <zalan>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, esprehn+autocc, ews-watchlist, kangil.han, simon.fraser
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
test case
none
Patch none

Description zalan 2020-07-17 16:58:31 PDT
<rdar://problem/64267520>
Comment 1 zalan 2020-07-17 17:00:30 PDT
Created attachment 404619 [details]
Patch
Comment 2 zalan 2020-07-17 17:01:10 PDT
Let's see what EWS says
Comment 3 zalan 2020-07-20 11:47:02 PDT
Created attachment 404734 [details]
Patch
Comment 4 zalan 2020-07-20 13:17:14 PDT
Created attachment 404749 [details]
Patch
Comment 5 zalan 2020-07-20 13:26:55 PDT
Created attachment 404751 [details]
Patch
Comment 6 zalan 2020-07-20 19:34:47 PDT
Created attachment 404785 [details]
test case
Comment 7 Simon Fraser (smfr) 2020-07-20 19:39:33 PDT
Comment on attachment 404751 [details]
Patch

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

> Source/WebCore/ChangeLog:11
> +        The event was initially specified to be non-cancelable in DOM Level 2 Events, but was changed to reflect existing interoperability between browsers.
> +        The most user facing behavior change here is that when the mousemove event is prevent-defaulted (canceled) content selection is not possible.

I'd like a little more detail here about the behavior of the other browsers.
Comment 8 zalan 2020-07-20 19:41:03 PDT
1. The test case preventDefaults the mousemove event while resizing the out-of-flow box.
2. mousemove used to be “non-cancelable” (https://www.w3.org/TR/DOM-Level-2-Events/events.html) but it got updated to “cancelable” (https://w3c.github.io/uievents/#event-type-mousemove)
3. Chrome impl is aligned with the latest version of the spec so when JS preventDefaults the mousemove, the drag (select) operation is not executed.
4. We still treat mousemove as a non-cancelable event and run the drag operation.
    swallowEvent = !dispatchMouseEvent(eventNames().mousemoveEvent, mouseEvent.targetNode(), 0, platformMouseEvent, FireMouseOverOut::Yes);
    if (!swallowEvent) {
        swallowEvent = handleMouseDraggedEvent(mouseEvent);
    }
^^ since the mousemove event is not cancelable, swallowEvent is false here even when JS calls preventDefault (or returns false).
5. However blink has TODO right at where the drag would happen:
EventHandler::HandleMouseMoveOrLeaveEvent()
…
  // TODO(crbug.com/346473): Since there is no default action for the mousemove
  // event we should consider doing drag&drop even when js cancels the
  // mouse move event.
  // https://w3c.github.io/uievents/#event-type-mousemove
…
So they might actually toggle this at some point.

Note: Firefox behaves like WebKit but not sure if it’s because their mousemove event is still non-cancelable or whether they already went ahead with what the TODO says here.
Comment 9 zalan 2020-07-21 09:10:10 PDT
Created attachment 404823 [details]
Patch
Comment 10 EWS 2020-07-21 09:36:00 PDT
Committed r264658: <https://trac.webkit.org/changeset/264658>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 404823 [details].