Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

Contact emails

xiaoc...@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

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: if (!Event.prototype.path) { Object.defineProperty(Event.prototype, 'path', { get() { return this.composedPath(); } }); }

Gecko: No signal Firefox does not support Event.path

WebKit: No signal Safari does not support Event.path

Web developers: Positive (https://github.com/web-platform-tests/interop-2022/issues/26)

Other signals:

Debuggability

Usage of this deprecated feature will be reported to the DevTools Issues Tab.

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1277431

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5726124632965120

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

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

xiaoc...@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

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.

Are we aware of bug reports from Apple caused by event.path? I'm not able to find any on bugs.webkit.org, but I could be doing it wrong.

Have you thought of ways to measure when event.path is called, and event.composedPath isn't (not sure if that's even possible)? Maybe that would show it's actually safe to remove.

if (!Event.prototype.path) { Object.defineProperty(Event.prototype, 'path', { get() { return this.composedPath(); } }); }

Given how simple this appears to be, I wonder if a better approach would be to ask Mozilla and Apple if they would be willing to accept patches to make event.path a legacy alias to event.composedPath - and then we can spec it in DOM or Compat. The alternative is to send deprecation messages for possibly a very long time, which doesn't really improve the compat situation for a very long time. Or, we can figure out how to measure the actual non-fallback usage of event.path and go from there.

Gecko: No signal Firefox does not support Event.path

WebKit: No signal Safari does not support Event.path

Web developers: Positive (https://github.com/web-platform-tests/interop-2022/issues/26)

That should probably be counted as positive support from Mozilla, rather than webdev support (no offense to James).

Other signals:

Debuggability

Usage of this deprecated feature will be reported to the DevTools Issues Tab.

Is this feature fully tested by web-platform-tests?

No

Flag name

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1277431

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5726124632965120

This intent message was generated by Chrome Platform Status.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGha_iNax9r8%2BXVQK%2Bf3hEdu5z-MDAh44FbKMOuAnrHL2Ew%40mail.gmail.com.

[Yoav Weiss]

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

xiaoc...@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

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.

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 and Event::composedPath 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%.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

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

[Philip Jägenstedt]

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

[Mike Taylor]

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).

[Xiaocheng Hu]

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.

[Xiaocheng Hu]

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.

[Yoav Weiss]

Thanks for the analysis! :) I think it may make sense to do a bit of a deeper dive into HA data to get a tighter bound on usage before coming up with a date.

[Philip Jägenstedt]

Hi Xiaocheng,

Thanks for doing this analysis, I think it's the first time I've seen categorization done this thoroughly using BigQuery, and I'm impressed :)

While one could also look at "e.path", I think what you have should be enough to get a good idea of the risk. Having identified a bunch of sites that might be broken, I think the next step is to take a random sample of them, say 10 sites. For each site, understand when that code path is reached in current Chrome, and then take a locally built version of Chrome with the API removed and reach that code path. What happens?

It sounds a lot that we have ~2500 site in the "hard fail" category, but I would bet that on closer inspection you will find:

• Code that you can't figure out how to even reach, which might be dead code
• Code that throws errors but everything works fine from the user's point of view
• Broken tracking or ads that the user could notice, but wouldn't really care about

And then finally, you might find cases that really are broken, but which are already broken in Firefox and Safari. If that is most of the remaining cases, then we have to weigh breaking those sites in Chrome and likely pushing them to be fixed (in all browsers) soonish, vs. them remaining broken in some browsers for what is very likely a longer time. In this case, I would say LGTM to minimizing overall breakage, for users of all browsers, by breaking the sites in Chrome after a reasonable deprecation period.

Best regards,

Philip

[Xiaocheng Hu]

Thanks for all the comments! I'll do a revisit later.

[Boo Blu]

• getting this 

[Xiaocheng Hu]

Hi all,

Here's an update as now the trunk has reached M109, the target milestone for the removal.

Event.path has been fully disabled on Canary & Dev, 50% on Beta and 1% on Stable. To help migration, an enterprise policy is also added to extend the availablility of Event.path until M115.

Despite the usage number still being high, I think the actual compat risks of the removal is low because:

- The feature is never supported by WebKit or Gecko, yet there's no bug reports for them

- Since the partial disabling, we have received only one complaint, which appears resolved by the enterprise policy

- HTTPArchive source analysis (done in June) shows that very few (<0.1%) pages actually have a usage that will fail after the removal; Many other pages are using the feature with Event.composedPath() or some ad hoc code as a fallback, or are not real usage (e.g., cloning every attribute of an Event object, hence triggering the use counter without actually using it)

[Chris Harrelson]

LGTM1

--

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9547aff7-15ad-420e-8574-d5bfc06b67c3n%40chromium.org.

[Yoav Weiss]

LGTM2. Thanks for the thorough analysis. Please roll this out carefully.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-9CRZ5ZRC6BVUU0-jcEE0jOyvqdOuvmU_fAUZ%2BeEOhrQ%40mail.gmail.com.

[TAMURA, Kent]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWPWqQYpYTz%2BJ9O_VegsT1rG%2By1pFT5H3wGtRTpASqiag%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[2016076ogooden via Chromestatus]

j jhuhsyhbhwbhb

[t.khan4 via Chromestatus]

bye

[t.khan4 via Chromestatus]

bye

[t.khan4 via Chromestatus]

bye

[t.khan4 via Chromestatus]

bye

[t.khan4 via Chromestatus]

bye

[Xiaocheng Hu]

Here's an update as the target milestone M109 has reached stable for quite a while.

On all platforms, other than Android WebView, the feature has been removed as planned. So far we haven't received any complaints.

For WebView, the original plan was to gradually roll out a removal via Finch. However, due to a Chromium-side implementation error, Finch was unable to change the feature status, which means it's still enabled at 100% in M109 stable. This has been fixed in M111. (See more details at https://chromium-review.googlesource.com/c/chromium/src/+/4188673)

To ensure a smooth removal, we will postpone the removal on WebView to M111.