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? > > - 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. > > - 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/CAJh39TNU%3DvDboWVRqR8Xa6tem5qA11Sicmpy9bN2H8fVJ4WXWw%40mail.gmail.com.
