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) <yoavwe...@chromium.org> wrote: > Is https://issues.chromium.org/issues/327409885 related here? > > On Mon, Mar 4, 2024 at 6:09 PM Mustaq Ahmed <mus...@chromium.org> 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 <mus...@chromium.org> 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 <rby...@chromium.org> wrote: >>> >>>> >>>> >>>> On Wed, Dec 6, 2023 at 5:08 PM Mustaq Ahmed <mus...@chromium.org> >>>> 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 <fla...@chromium.org> >>>>> wrote: >>>>> >>>>>> On Wed, Dec 6, 2023 at 12:18 PM Rick Byers <rby...@chromium.org> >>>>>> 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 <rby...@chromium.org> >>>>>>> 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 <mus...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emailsmus...@chromium.org, fla...@chromium.org >>>>>>>>> >>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >>>>>>>>> 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 blink-dev+unsubscr...@chromium.org. >> 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5gdqO87t5hHs%3DDeb%3D2SF%2B-cdnFE1BWMzHVvgjdFqV4CA%40mail.gmail.com.
