LGTM2 On Tue, Mar 12, 2024, 13:03 Chris Harrelson <[email protected]> wrote:
> 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/CAOmohSK4LBKQjCx_MPzdGzCnpAy4mDbfQxB27Mt73Ahb%2BXE-HA%40mail.gmail.com.
