Bug 214513 - [UI Events] Make mousemove cancelable
Summary: [UI Events] Make mousemove cancelable
Alias: None
Product: WebKit
Classification: Unclassified
Component: UI Events (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: zalan
Keywords: InRadar
Depends on:
Reported: 2020-07-17 16:58 PDT by zalan
Modified: 2020-07-21 09:36 PDT (History)
5 users (show)

See Also:

Patch (1.76 KB, patch)
2020-07-17 17:00 PDT, zalan
no flags Details | Formatted Diff | Diff
Patch (5.96 KB, patch)
2020-07-20 11:47 PDT, zalan
no flags Details | Formatted Diff | Diff
Patch (6.62 KB, patch)
2020-07-20 13:17 PDT, zalan
no flags Details | Formatted Diff | Diff
Patch (6.72 KB, patch)
2020-07-20 13:26 PDT, zalan
no flags Details | Formatted Diff | Diff
test case (3.71 KB, text/html)
2020-07-20 19:34 PDT, zalan
no flags Details
Patch (7.22 KB, patch)
2020-07-21 09:10 PDT, zalan
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description zalan 2020-07-17 16:58:31 PDT
Comment 1 zalan 2020-07-17 17:00:30 PDT
Created attachment 404619 [details]
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]
Comment 4 zalan 2020-07-20 13:17:14 PDT
Created attachment 404749 [details]
Comment 5 zalan 2020-07-20 13:26:55 PDT
Created attachment 404751 [details]
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]

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:
  // 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]
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].