Sounds good to me! LGTM1 On Tue, Mar 12, 2024 at 9:53 AM Mustaq Ahmed <[email protected]> wrote:
> 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 > > > On Wed, Mar 6, 2024 at 10:06 AM Mustaq Ahmed <[email protected]> wrote: > >> No, issue 327409885 is related to the PSA on canceling mousedown in >> iframe >> <https://groups.google.com/a/chromium.org/g/blink-dev/c/RYzJrvPzHss/m/QsopwzYQAAAJ> >> . >> >> >> On Wed, Mar 6, 2024 at 5:25 AM Yoav Weiss (@Shopify) < >> [email protected]> wrote: >> >>> 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 >>>>>>>>>>> >>>>>>>>>>> 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 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/CAB0cuO5AOvd%3DjxHVkps8%3DfuWcaX4hpCXY46rYvmGW8H2hNiChw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5AOvd%3DjxHVkps8%3DfuWcaX4hpCXY46rYvmGW8H2hNiChw%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/CAOMQ%2Bw8p7OT%3DKbMZxBQSQE2hB8_aUYY3B15yaj%2B3NGU1LU8XwA%40mail.gmail.com.
