Hey Mustaq,
Thanks for pushing to get this long-time interop issue addressed! I assume
cancelling the mousedown (but not the mousemove) still prevents selection
and drag-and-drop in all browsers, is that right? That's the pattern I'd
expect is most common. Also, what's the behavior of pointermove for mice
today and after this change?

What's your plan for if the UseCounter comes back high? FWIW, I'm betting
that it will. First I expect it'll be common for sites to cancel all the
mouse events. If my understanding above is correct, then perhaps you want
to exclude those from your UseCounter since the behavior won't change in
those cases? But secondly, given past history with some major sites, I
suspect there might be a long tail of sites that are lightly broken here.
Maybe worth doing a finch-based rollout to mitigate the risk? I'd support
going up to stable 1% now to see if we learn of any issues. I'm
particularly worried about enterprise (LOB) apps which are often
chromium-only. We'll see what Enterprise review says on the launch, but
they might want <https://www.chromium.org/developers/enterprise-changes/> a
mention in the release notes and a policy opt-out. Then again perhaps since
the breakage is likely to be rare and cosmetic, just doing a finch-based
roll-out (and hitting a finch killswitch on reports of any issues) should
be enough to mitigate the risk.

You might also consider enabling UKM support
<https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc?q=ukm_features&ss=chromium>
for
your UseCounter to get some sample URLs, though again I'd worry you might
get lots of hits but not be able to easily reproduce any obvious breakage.
Alternately it might be most useful to just spot check 5-10 major sites
which have mouse dragging behavior with DOM (not just canvas) and catalog
how they avoid getting unintended selection (eg. do they cancel selectstart
or use user-select: none). I think mapping sites are an obvious example,
gmail has some message dragging behavior I think, not sure what else.

Rick

On Mon, Dec 4, 2023 at 2:35 PM Mustaq Ahmed <mus...@chromium.org> wrote:

> Contact emailsmus...@chromium.org, fla...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/uievents/#event-type-mousemove
>
> Summary
>
> Canceling mousemove will not prevent text selection or drag-and-drop.
> Chrome allowed cancelling mousemove events to prevent other APIs like text
> selection (and even drag-and-drop in the past). This does not match other
> major browsers; nor does it conform to the UI Event spec:
> https://w3c.github.io/uievents/#event-type-mousemove Through this
> feature, the default-action of mousemove becomes none. Text selection and
> drag-and-drop can still be prevented through cancelling selectstart and
> dragstart events respectively, which are spec compliant and fully
> interoperable.
>
>
> Blink componentBlink>Input
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput>
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This feature will make Chrome fully interoperable. Chrome is currently
> failing the corresponding WPT (a part of Interop 2023) while both Mozilla
> and WebKit have started passing the WPT recently. There is a bit of compat
> risk. We attempted it twice in the past but had to revert for two different
> reasons: in 2014 we faced a text-selection regression
> https://crbug.com/485892 on an app that no longer shows the problem
> (because app event handling changed), then in 2018 we faced a drag-and-drop
> regression https://crbug.com/878392 that is irrelevant now (because
> Chrome drag-and-drop changed). For our current attempt the risk from
> text-selection remains, and we need to expose the feature to be able to
> assess the risk. We have added a use-counter and turned on the feature as
> "experimental" on M121 to observe field data before shipping it.
>
>
> *Gecko*: Shipped/Shipping (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1823663)
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=262878
> )
>
> *Web developers*: Positive (https://crbug.com/346473#c6)
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?Yes
>
>
> https://wpt.fyi/results/uievents/mouse/mousemove_prevent_default_action.tentative.html?label=experimental&label=master&aligned
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameMouseDragOnCancelledMouseMove
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/346473
>
> MeasurementWe have added the use-counter kMouseDragOnCancelledMouseMove
> to track possible regressions in the wild.
>
> Sample links
> https://codepen.io/mustaqahmed/full/wvNYGEP
>
> Estimated milestones
> Shipping on desktop 122
> Shipping on Android 122
> Shipping on WebView 122
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5145305056280576
>
> This intent message was generated by Chrome Platform Status
> <https://chromestatus.com/>.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO7reN%2B6Wb_N99jNm_aJY7fhhQ1ncCrh_J_%2BFCLdASm0eg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO7reN%2B6Wb_N99jNm_aJY7fhhQ1ncCrh_J_%2BFCLdASm0eg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8BJxkN7SmBJT%3Du6EjiT5_jYMHFy7V6yFG9nOQiqJDAoQ%40mail.gmail.com.

Reply via email to