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/CAARdPYc_MvgO-57m%3DZsDP%2BPsUZGB_M5vHA8ynnjcvL9CPdSjOw%40mail.gmail.com.
