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/6d3ecf10-5ab3-6b39-e1de-cc7b4fb75a2c%40chromium.org.
