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 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/CAFUtAY9E5JPJS2C_rMz7JBXEV3UA7dedhxp4%2BVT4W_ixk5CmMw%40mail.gmail.com.
