Is https://issues.chromium.org/issues/327409885 related here?
On Mon, Mar 4, 2024 at 6:09 PM Mustaq Ahmed <[email protected]> wrote: > 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. > > On Wed, Jan 17, 2024 at 1:48 PM Mustaq Ahmed <[email protected]> wrote: > >> 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/CAB0cuO4KQ%3DcN7O6eE70AWuw-y-Q7LtR_TiZTYrvz8giVfdQrNA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO4KQ%3DcN7O6eE70AWuw-y-Q7LtR_TiZTYrvz8giVfdQrNA%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/CAOmohSJX0XcZui6UkeWpzy2jf5joPdcLCjxyzJ0-83y_CMA6-w%40mail.gmail.com.
