Bug 214513 – [UI Events] Make mousemove cancelable

• Component: UI Events
• Status: RESOLVED FIXED

[alan]

<rdar://problem/64267520>

[alan]

Created attachment 404619 [details]
Patch

[alan]

Let's see what EWS says

[alan]

Created attachment 404734 [details]
Patch

[alan]

Created attachment 404749 [details]
Patch

[alan]

Created attachment 404751 [details]
Patch

[alan]

Created attachment 404785 [details]
test case

[Simon Fraser (smfr)]

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.

[alan]

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.

[alan]

Created attachment 404823 [details]
Patch

[EWS]

Committed r264658: <https://trac.webkit.org/changeset/264658>

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