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. On Thu, Dec 7, 2023 at 10:14 AM Rick Byers <[email protected]> wrote: > > > On Wed, Dec 6, 2023 at 5:08 PM Mustaq Ahmed <[email protected]> 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 <https://codepen.io/mustaqahmed/full/wvNYGEP> 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 <[email protected]> wrote: >> >>> On Wed, Dec 6, 2023 at 12:18 PM Rick Byers <[email protected]> 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 >>> <https://bugs.chromium.org/p/chromium/issues/detail?id=954423&q=overscroll-behavior%20root&can=2>) >>> 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. > >> >>>> - 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. >>> >>> Rick >>>> >>>> On Tue, Dec 5, 2023 at 3:42 PM Rick Byers <[email protected]> wrote: >>>> >>>>> 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 <[email protected]> >>>>> wrote: >>>>> >>>>>> Contact [email protected], [email protected] >>>>>> >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO7enE54MZOPKYpENrDeQOHYOiKfGVUBQYR2S%2Bx-TkpSMg%40mail.gmail.com.
