Hi blink-dev, I've done an analysis on HTTP Archive (https://bit.ly/3uHALsd), and found that at least 0.2% pages will break if Event.path is removed. The actual number should be higher (maybe 1%?) since the analysis is based on searching the regex r'(ev|event)\.path' in JavaScript code, so the analysis couldn't find a usage if the code has been aggressively minified with variables renamed.
My current plan is that we'll target M109, the first release in 2023. Before its removal, we'll: - Use on a deprecation message in DevTools to decrease the usage - Do outreach if needed - Starting from September 2022, or if the known breakage number drops below a threshold (mabye 0.05%?), disable it on all non-Stable channels (via finch) to further speed up decreasing the usage. On Wed, Feb 9, 2022 at 9:59 AM Xiaocheng Hu <xiaoche...@chromium.org> wrote: > I'm still working on HTTP Archive to see the actual usage patterns of > Event.path. I also suspect that many won't really break with Event.path > removed, since I'm not aware of any Apple bugs, either. > > I'll update this thread when I'm done. > > On Wed, Feb 9, 2022 at 9:28 AM Mike Taylor <miketa...@chromium.org> wrote: > >> Thanks for digging into this Philip! Agree that HTTPArchive analysis will >> be pretty helpful to help us make a decision. >> >> Thinking again about the lack of (many) Firefox and Safari bugs - that >> gives me some hope that it might be safe to remove from Chromium (assuming >> we don't find that sites are UA-sniffing to only use event.path for >> Chromium browsers). >> >> On 2/9/22 11:46 AM, Philip Jägenstedt wrote: >> >> Here's a first cut at httparchive analysis: >> >> SELECT page, url >> FROM `httparchive.latest.response_bodies_desktop` >> WHERE STRPOS(body, 'event.path') > 0 >> AND STRPOS(body, 'event.composedPath()') = 0; >> >> That finds over 32k cases. Categorizing these based on context and >> analyzing how each case would break would really help here. >> >> The very first case I looked at was like this: >> >> function getRealEventTarget(event, ELEMENT) { >> var path = [] >> if (event.path) { >> path = event.path >> } >> if (event.originalEvent && event.originalEvent.path) { >> path = event.originalEvent.path >> } >> if (path && path.length > 0) { >> if (ELEMENT && path.indexOf(ELEMENT) >= 0) { >> return ELEMENT >> } else { >> return path[0] >> } >> } >> return event.target >> } >> >> At first glance this seems like a problem and that things could break, >> but then we need to look at if it's already broken in Firefox and Safari. >> It may well turn out that as actually used, it's harmless. >> >> Best regards, >> Philip >> >> On Wed, Feb 9, 2022 at 5:37 PM Philip Jägenstedt <foo...@chromium.org> >> wrote: >> >>> On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss <yoavwe...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Wednesday, February 9, 2022 at 2:49:55 AM UTC+1 Mike Taylor wrote: >>>> >>>>> Hey Xiaocheng, >>>>> >>>>> Thanks for working on improving interop! A few thoughts and questions >>>>> below. >>>>> >>>>> On 2/8/22 7:25 PM, Xiaocheng Hu wrote: >>>>> >>>>> Contact emails xiaoche...@chromium.org >>>>> >>>>> Explainer None >>>>> >>>>> Specification None. Not a standard feature. >>>>> >>>>> Summary >>>>> >>>>> Event.path is a non-standard API that returns the event's path, which >>>>> is an array of the objects on which listeners will be invoked. It is >>>>> supported by Blink only, causing web compatibility issues. Web developers >>>>> should switch to the equivalent standard API Event.composedPath(), which >>>>> returns the same result. >>>>> >>>>> >>>>> Blink component Blink>DOM >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EDOM> >>>>> >>>>> TAG review >>>>> >>>>> TAG review status Not applicable >>>>> >>>>> Risks >>>>> >>>>> >>>>> Interoperability and Compatibility >>>>> >>>>> The removal of this API should improve interoperability, as it's >>>>> supported by Blink only. It still has 18% usage as of Feb 2022 ( >>>>> https://chromestatus.com/metrics/feature/timeline/popularity/345), so >>>>> we will only deprecate it for now, and will not remove it before the usage >>>>> drops low enough. We expect low compatibility risks, since there is an >>>>> equivalent standard API (Event.composedPath()) by all browsers, and the >>>>> following polyfill should also keep existing sites functioning with >>>>> minimum >>>>> changes: >>>>> >>>>> 18% is a _lot_ of usage. So much that I'm surprised there aren't >>>>> dozens of compat bugs reported against Firefox. In >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1697590#c0 there are >>>>> only 2 linked site bugs. And there's only 3 in >>>>> https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+composedPath >>>>> (the last one being from 2019). >>>>> >>>>> I wonder how much of that 18% is feature detection and fallback >>>>> codepaths >>>>> <https://github.com/search?l=JavaScript&q=composedPath+event.path&type=Code> >>>>> . >>>>> >>>> >>>> Yeah, that 18% is unreasonably high... >>>> I think it'd be good to add a non-IDL based counter that counts when >>>> both Event::path >>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/events/event.cc;l=287;bpv=1;bpt=0> >>>> and >>>> Event::composedPath >>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/events/event.cc;l=293;bpv=1;bpt=0> >>>> are >>>> accessed. (e.g. by adding 2 booleans or a bitmask on Event indicating when >>>> any of them was touched and triggering the counter when both have been) >>>> Then we can assume that counts feature-detection/fallback and subtract >>>> that counter from the 18%. >>>> >>> >>> Based on past cases, I'm pretty sure most of the usage here is due to >>> event copying, where all of the properties of event instances are copied to >>> a new object. So I think we should basically ignore the 18% number and >>> treat the risk as unknown. >>> >>> A use counter that tries to better measure the risk here would be nice, >>> but I actually don't see how to measure it. Consider this code: >>> >>> function(event) { >>> var path = event.path; >>> if (!path) { >>> path = event.composedPath() >>> } >>> doStuffWith(path); >>> } >>> >>> This would never hit the composedPath() code path, and is >>> indistinguishable to code that only relies on event.path, from the point of >>> view of use counter instrumentation. >>> >>> I think that httparchive analysis here is our best tool, and in fact >>> that *only* httparchive analysis could be enough to convince us that >>> there's no problem here, if we fail to find any breaking cases. But even >>> then, we should probably have a fairly long deprecation period. >>> >>> If we go ahead and deprecate this, what do you think the deprecation >>> message should say about eventual removal? >>> >>> Best regards, >>> Philip >>> >> >> -- 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/CAFqEGhb2i0S%2BJYpwBsBOBcvBAF4g7eZZi8sxjzjFHAHSB3Ea9w%40mail.gmail.com.