Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[Boo Blu]

   
   - getting this 


On Wednesday, March 30, 2022 at 1:30:23 PM UTC-4 xiaoc...@chromium.org 
wrote:

> Thanks for all the comments! I'll do a revisit later.
>
> On Wed, Mar 30, 2022 at 5:53 AM Philip Jägenstedt  
> wrote:
>
>> 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
>>
>> On Wed, Mar 9, 2022 at 4:04 PM Yoav Weiss  wrote:
>>
>>> 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.
>>>
>>> On Thursday, March 3, 2022 at 9:23:50 PM UTC+1 Xiaocheng Hu wrote:
>>>
 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  
 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  
> 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]
>> }
>> 

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

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

On Wed, Mar 30, 2022 at 5:53 AM Philip Jägenstedt 
wrote:

> 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
>
> On Wed, Mar 9, 2022 at 4:04 PM Yoav Weiss  wrote:
>
>> 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.
>>
>> On Thursday, March 3, 2022 at 9:23:50 PM UTC+1 Xiaocheng Hu wrote:
>>
>>> 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 
>>> 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 
 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.
>
> Be

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[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

On Wed, Mar 9, 2022 at 4:04 PM Yoav Weiss  wrote:

> 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.
>
> On Thursday, March 3, 2022 at 9:23:50 PM UTC+1 Xiaocheng Hu wrote:
>
>> 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 
>> 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 
>>> 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 
 wrote:

> On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Wednesday, February 9, 2022 at 2:49:55 AM UTC+1 Mike Taylor wrote

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

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

On Wed, Feb 9, 2022 at 9:59 AM Xiaocheng Hu  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  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 
>> wrote:
>>
>>> On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss 
>>> 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
> 
>
> 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

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

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

On Wed, Feb 9, 2022 at 9:28 AM Mike Taylor  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 
> wrote:
>
>> On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss 
>> 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
 

 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%.
>>>
>>
>> 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 count

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

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


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  
wrote:


On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss
 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




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


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

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[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

On Wed, Feb 9, 2022 at 5:37 PM Philip Jägenstedt 
wrote:

> On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss  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
>>> 
>>>
>>> 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%.
>>
>
> 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,
> Phili

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[Philip Jägenstedt]

On Wed, Feb 9, 2022 at 10:50 AM Yoav Weiss  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
>> 
>>
>> 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%.
>

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/CAARdPYf2oYbdG44_jand7F5yovDZ6SjUajaQJ1xHqEmSVJ_a%2Bw%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[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 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 
> 
>
> 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%.


> 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+unsubscr...@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
>  
> 

Re: [blink-dev] Intent to Deprecate and Remove: Event.path

[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

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 




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+unsubscr...@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 
.


--
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/37184c99-a5ca-0dbd-1a19-5e15934c2bc5%40chromium.org.

[blink-dev] Intent to Deprecate and Remove: Event.path

[Xiaocheng Hu]

Contact emailsxiaoche...@chromium.org

ExplainerNone

SpecificationNone. 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 componentBlink>DOM


TAG review

TAG review statusNot 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 bughttps://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+unsubscr...@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.