Intent to Ship: Interoperable mousemove default action

[Mustaq Ahmed]

Contact emails

mus...@chromium.org, fla...@chromium.org

Explainer

None

Specification

https://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 component

Blink>Input

TAG review

None

TAG review status

Not 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?

Yes

https://wpt.fyi/results/uievents/mouse/mousemove_prevent_default_action.tentative.html?label=experimental&label=master&aligned

Flag name on chrome://flags

None

Finch feature name

MouseDragOnCancelledMouseMove

Requires code in //chrome?

False

Tracking bug

https://crbug.com/346473

Measurement

We 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.

[Rick Byers]

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 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 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

--
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+...@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.

[Rick Byers]

API owners met and discussed this one briefly today. There was agreement that more work needs to be done to demonstrate the compat risk is low enough to ship this breaking change. A few points:

• If you'd like to do a finch trial to gather data (up to stable 1%) we're supportive of that.
• Mike Taylor argued that you're not likely to learn too much useful from a finch trial since people seem not to report bugs for things that fail for a seemingly random 1% of their users, and perhaps the idea of surveying a few sites would be more effective at finding real breakage. Of course UKM + Finch might be a good way to find URLs to test.
• Mike also argued that in his experience, he'd expect sites like mapping apps to have engine-specific conditional code around their event handling, so that increases the risk.
• Philip and I discussed that if there is evidence of real breakage we can't accept, we should propose changing the spec here - it seems like it would be very reasonable if cancelling the first mousemove event in a sequence canceled text selection (just like cancelling the first touchmove prevents scrolling). But if we have reasonable evidence that it's non-breaking, we're happy to just align with WebKit and Gecko for improved interoperability.
• All agreed we're willing to take some risk here to achieve interop quickly and don't want to impose too much of a burden of proof, especially since the severity of breakage is likely low. We just need some more evidence that the risk is manageable. 

Perhaps the most pragmatic path would be something like:

1. Survey at least 5 sites with mouse drag involving DOM and explain why they're unimpacted (cancelling mousedown? cancelling selectionstart? or just user-select: none?). If you find one that is indeed broken, revisit plan.
2. Work with the enterprise team on release notes & plan - i.e. either finch roll out with commitment to killswitch if we get reports of enterprise breakage, or add a policy knob opt-out
3. Go for 100% but be prepared to killswitch if there are non-trivial reports of breakage, then revisit with either a migration plan (outreach, blog post) or proposed spec change

WDYT?

Rick

[Robert Flack]

On Wed, Dec 6, 2023 at 12:18 PM Rick Byers <rby...@chromium.org> wrote:

API owners met and discussed this one briefly today. There was agreement that more work needs to be done to demonstrate the compat risk is low enough to ship this breaking change. A few points:

• If you'd like to do a finch trial to gather data (up to stable 1%) we're supportive of that.
• Mike Taylor argued that you're not likely to learn too much useful from a finch trial since people seem not to report bugs for things that fail for a seemingly random 1% of their users, and perhaps the idea of surveying a few sites would be more effective at finding real breakage. Of course UKM + Finch might be a good way to find URLs to test.

We have landed a metric which specifically checks for cases where the mousemove is preventDefaulted but a selection starts (i.e. selectstart wasn't prevented, there was no user-select: none, and so the selection does change). Right now this is a UMA but we could also add UKM and get sites from this. Mustaq WDYT about adding UKM for this and running the 1% finch trial?

• Mike also argued that in his experience, he'd expect sites like mapping apps to have engine-specific conditional code around their event handling, so that increases the risk.
• Philip and I discussed that if there is evidence of real breakage we can't accept, we should propose changing the spec here - it seems like it would be very reasonable if cancelling the first mousemove event in a sequence canceled text selection (just like cancelling the first touchmove prevents scrolling). But if we have reasonable evidence that it's non-breaking, we're happy to just align with WebKit and Gecko for improved interoperability.

Agreed, though it may be breaking for other engines to change behavior too though, right? E.g. we are in a similar situation with overscroll-behavior on the root element (crbug.com/954423) where changing either behavior to the other will have compat risk.

• All agreed we're willing to take some risk here to achieve interop quickly and don't want to impose too much of a burden of proof, especially since the severity of breakage is likely low. We just need some more evidence that the risk is manageable. 

Perhaps the most pragmatic path would be something like:

1. Survey at least 5 sites with mouse drag involving DOM and explain why they're unimpacted (cancelling mousedown? cancelling selectionstart? or just user-select: none?). If you find one that is indeed broken, revisit plan.
2. Work with the enterprise team on release notes & plan - i.e. either finch roll out with commitment to killswitch if we get reports of enterprise breakage, or add a policy knob opt-out
3. Go for 100% but be prepared to killswitch if there are non-trivial reports of breakage, then revisit with either a migration plan (outreach, blog post) or proposed spec change

WDYT?

This sounds reasonable. I think running the 1% experiment with the targeted metric (cases where selection now happens when it didn't used to) should help us gain confidence.

[Mustaq Ahmed]

> 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?

I just confirmed that Chrome (and Firefox and Safari too) already prevents both selection and drag-and-drop when mousedown or pointerdown is cancelled.  So sites canceling all the mouse events will work fine.

> We have landed a metric which specifically checks for cases where the mousemove is preventDefaulted but a selection starts (i.e. selectstart wasn't prevented, there was no user-select: none, and so the selection does change). Right now this is a UMA but we could also add UKM and get sites from this. Mustaq WDYT about adding UKM for this and running the 1% finch trial?

Adding UKM and running a 1% finch trial sounds good.

Perhaps we can run a Canary/Dev/Beta trial even now (on M121)?

[Rick Byers]

On Wed, Dec 6, 2023 at 5:08 PM Mustaq Ahmed <mus...@chromium.org> wrote:

> 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?

I just confirmed that Chrome (and Firefox and Safari too) already prevents both selection and drag-and-drop when mousedown or pointerdown is cancelled.  So sites canceling all the mouse events will work fine.

Great, thanks! That definitely lowers my concern.

> We have landed a metric which specifically checks for cases where the mousemove is preventDefaulted but a selection starts (i.e. selectstart wasn't prevented, there was no user-select: none, and so the selection does change). Right now this is a UMA but we could also add UKM and get sites from this. Mustaq WDYT about adding UKM for this and running the 1% finch trial?

Adding UKM and running a 1% finch trial sounds good.

Perhaps we can run a Canary/Dev/Beta trial even now (on M121)?

Yep, you can do whatever you want for canary/dev and you have API owner approval for Beta and Stable up to 1% if you want it. Perhaps beta data alone would be compelling enough for API owners to approve this (with an understanding, like always, that we'd kill-switch it on reports of non-trivial stable breakage).

On Wed, Dec 6, 2023 at 12:34 PM Robert Flack <fla...@chromium.org> wrote:

On Wed, Dec 6, 2023 at 12:18 PM Rick Byers <rby...@chromium.org> wrote:

API owners met and discussed this one briefly today. There was agreement that more work needs to be done to demonstrate the compat risk is low enough to ship this breaking change. A few points:

• If you'd like to do a finch trial to gather data (up to stable 1%) we're supportive of that.
• Mike Taylor argued that you're not likely to learn too much useful from a finch trial since people seem not to report bugs for things that fail for a seemingly random 1% of their users, and perhaps the idea of surveying a few sites would be more effective at finding real breakage. Of course UKM + Finch might be a good way to find URLs to test.

We have landed a metric which specifically checks for cases where the mousemove is preventDefaulted but a selection starts (i.e. selectstart wasn't prevented, there was no user-select: none, and so the selection does change). Right now this is a UMA but we could also add UKM and get sites from this. Mustaq WDYT about adding UKM for this and running the 1% finch trial?

Ah that makes sense. Sorry I only took a quick glance at the code for the UseCounter and missed that. That's indeed much more relevant than I was thinking, maybe it won't be so high after all and that can give us good confidence to ship?

• Mike also argued that in his experience, he'd expect sites like mapping apps to have engine-specific conditional code around their event handling, so that increases the risk.
• Philip and I discussed that if there is evidence of real breakage we can't accept, we should propose changing the spec here - it seems like it would be very reasonable if cancelling the first mousemove event in a sequence canceled text selection (just like cancelling the first touchmove prevents scrolling). But if we have reasonable evidence that it's non-breaking, we're happy to just align with WebKit and Gecko for improved interoperability.

Agreed, though it may be breaking for other engines to change behavior too though, right? E.g. we are in a similar situation with overscroll-behavior on the root element (crbug.com/954423) where changing either behavior to the other will have compat risk.

Oh good point. And breaking intended selection is arguably worse than allowing unintended selection. Ok, that's a further argument for us accepting more risk here, thanks. 

[Mustaq Ahmed]

A quick update: our use-counter on Chrome 122 Canary/Dev came out higher than we expected---it is suggesting that at most 0.11% page loads are affected.

We will expand the finch trail to 50% Beta plus 1% Stable now to get more data, and then look into other directions like adding UKM or fine tuning the use-counter.

[Mustaq Ahmed]

UKM data shows that only a few popular sites are affecting our use-counters.  We already confirmed that one of those sites is not broken at all, only showing text selection on menu items.  We are expecting to conclude soon after investigating all those sites.

[Yoav Weiss (@Shopify)]

Is https://issues.chromium.org/issues/327409885 related here?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4KQ%3DcN7O6eE70AWuw-y-Q7LtR_TiZTYrvz8giVfdQrNA%40mail.gmail.com.

[Mustaq Ahmed]

No, issue 327409885 is related to the PSA on canceling mousedown in iframe.

[Mustaq Ahmed]

Hi API Owners:

We concluded this feature is safe to ship after investigating the few sites that are affecting our use-counter:

- None of UKM reported sites show any usability problem in our investigation.

- On one of those sites, a mouse drag over menu items starts text selection (w/o affecting usability).  The site shows the same problem with Firefox and Safari; and even on Chrome Stable (w/o the feature) but for certain menu-item drags.

- The UKM usage percentages for those sites add up to match the ~0.12% usage shown by our use-counter.  So no sites affecting our use-counter seem to have been left out by UKM.

In case this is still needed, we are rolling out the 1% Stable experiment that we promised on Jan 17.

Mustaq

[Chris Harrelson]

Sounds good to me! LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5AOvd%3DjxHVkps8%3DfuWcaX4hpCXY46rYvmGW8H2hNiChw%40mail.gmail.com.

[Yoav Weiss (@Shopify)]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSK4LBKQjCx_MPzdGzCnpAy4mDbfQxB27Mt73Ahb%2BXE-HA%40mail.gmail.com.