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.
