Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

['Noam Rosenthal' via blink-dev]

Update on this: we're still interested in the next step but it's in the 
back burner until mutation event deprecation is complete, to avoid related 
noise.

On Wednesday, April 3, 2024 at 12:52:23 PM UTC+1 Noam Rosenthal wrote:

> On Tue, Apr 2, 2024 at 3:12 PM Aaron Leventhal  
> wrote:
>
>> A good start would be Scott O'Hara from Microsoft. He would know others 
>> to loop in.
>>
>
> Thanks, will reach out. We see this deprecation as a long-haul thing, and 
> sent this I2D to start the conversation. Thanks for the pointers!
>

-- 
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/4c7abd3c-554e-4100-be0a-79a6a0181992n%40chromium.org.

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

[Noam Rosenthal]

On Tue, Apr 2, 2024 at 3:12 PM Aaron Leventhal 
wrote:

> A good start would be Scott O'Hara from Microsoft. He would know others to
> loop in.
>

Thanks, will reach out. We see this deprecation as a long-haul thing, and
sent this I2D to start the conversation. Thanks for the pointers!

-- 
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/CAJn%3DMYa1fBDg6dZQkc9smfU1x7in%3DWGyy6Br2B2stmgmrZHwZw%40mail.gmail.com.

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

['Aaron Leventhal' via blink-dev]

A good start would be Scott O'Hara from Microsoft. He would know others to
loop in.

On Tue, Apr 2, 2024 at 4:03 AM Yoav Weiss (@Shopify) 
wrote:

> Hmm, would it make sense then to work with the accessibility community to
> get them to move to mutation observers before attempting to remove here?
> Do we know folks with contacts in these circles?
>
> ^^ +Aaron Leventhal 
>
> On Fri, Mar 29, 2024 at 7:01 PM Ian Kilpatrick 
> wrote:
>
>>
>>
>> On Fri, Mar 29, 2024 at 4:33 AM Noam Rosenthal 
>> wrote:
>>
>>>
>>>
>>> On Fri, Mar 29, 2024 at 6:33 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
 On top of Domenic's questions, have we tried to estimate the risk here?
 Even if it's Chromium-only, there could be Enterprise or embedded scenarios
 that somehow rely on it.

>>> Yes, and we're willing to keep the old behavior as an enterprise policy,
>>> at least temporarily.
>>>
>>>
 Do we know how often this blur event actually fires?

>>>
>>> There's no way to find out unfortunately. This event is currently fired
>>> for every removal, and there could be event listeners that handle it, but
>>> there is no way to tell if functionality builds on it, or at least I
>>> couldn't think of one (happy for suggestion). We wanted to disable it in a
>>> finch and If we decide that we would rather leave things as is, staying
>>> incompatible with Gecko/WebKi/the standard, and also keeping the quirkiness
>>> of being able to run a script synchronously while a node is removed, I'm
>>> totally OK with that, but that needs to be a conscious decision.
>>>
>>>

 On Fri, Mar 29, 2024 at 5:28 AM Domenic Denicola 
 wrote:

>
>
> On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal <
> nrosent...@chromium.org> wrote:
>
>> Contact emailsnrosent...@chromium.org, d...@chromium.org
>>
>> ExplainerNone
>>
>
> A few paragraphs, including e.g. example code and how it behaves
> differently before/after the change, would help clarify this for web
> developers.
>

>>> Sure!
>>> Writing those here, if you think they need to be in some repo that's
>>> fine.
>>> This will mainly affect code that uses global `focus` `blur` event
>>> listeners to track the active element, for example in a form:
>>>
>>> ```js
>>> form.addEventListener("focus", () => { trackActiveElementChange() }, {
>>> capture: true});
>>> form.addEventListener("blur", () => { trackActiveElementChange() },
>>> {capture: true});
>>> ```
>>>
>>> Now, since the active element might be removed without a `blur` event,
>>> the same can be achieved with mutation observers:
>>> ```js
>>> form.addEventListener("focus", () => { trackActiveElementChange() }, {
>>> capture: true});
>>> new MutationObserver(entries => {
>>>   if (Array.from(entries).some(entry => entry.removedNodes.length)
>>>  trackActiveElementChange();
>>> }).observe(form);
>>> ```
>>>
>>> In essence the author can check that the node either lost focus or was
>>> removed, but you don't have an event that tells you that "either" happened.
>>> So all the use cases can be covered, but of course there is a backwards
>>> compat risk as mentioned in this thread. We should make a decision on how
>>> to go forward as a balance between the backwards-compat risk and the
>>> other-browser-compat risk.
>>>
>>> This is done as part of an effort to see if we can get rid of (as many
>>> as possible) scripts that can run in the middle of a DOM operation.
>>> This one and events on iframe removal are the only ones remaining.
>>>
>>
>> To provide a little more context - activeElement tracking is used heavily
>> by most webapp having non-trivial a11y implementations.
>>
>> An example of this pattern is something like:
>>
>> https://github.com/tridactyl/tridactyl/blob/f49e1c94bcd481fdc86fb219335bafc4ce0f25ab/src/content.ts#L180-L187
>> (From the first page of a github search of activeElement + setInterval).
>> (Above is for a Firefox specific extension I think - so doesn't have any
>> if (FIREFOX) for the interval checking).
>> (Not this case exactly also - but same pattern).
>>
>> setInterval checking is done for other browsers as there isn't a great
>> way to check for activeElement changes (maybe there should be async events?
>> - but thats a separate discussion).
>> But web developers might have only done the setInterval pattern for
>> Firefox/Safari.
>>
>> Ian
>>
>> --
>>> 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/CAJn%3DMYbiys600Gk5c%3DsW8B-iJOzRHqWq6Puc5nm8f-78zvxJvw%40mail.gmail.com
>>> 

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

[Yoav Weiss (@Shopify)]

Hmm, would it make sense then to work with the accessibility community to
get them to move to mutation observers before attempting to remove here?
Do we know folks with contacts in these circles?

^^ +Aaron Leventhal 

On Fri, Mar 29, 2024 at 7:01 PM Ian Kilpatrick 
wrote:

>
>
> On Fri, Mar 29, 2024 at 4:33 AM Noam Rosenthal 
> wrote:
>
>>
>>
>> On Fri, Mar 29, 2024 at 6:33 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> On top of Domenic's questions, have we tried to estimate the risk here?
>>> Even if it's Chromium-only, there could be Enterprise or embedded scenarios
>>> that somehow rely on it.
>>>
>> Yes, and we're willing to keep the old behavior as an enterprise policy,
>> at least temporarily.
>>
>>
>>> Do we know how often this blur event actually fires?
>>>
>>
>> There's no way to find out unfortunately. This event is currently fired
>> for every removal, and there could be event listeners that handle it, but
>> there is no way to tell if functionality builds on it, or at least I
>> couldn't think of one (happy for suggestion). We wanted to disable it in a
>> finch and If we decide that we would rather leave things as is, staying
>> incompatible with Gecko/WebKi/the standard, and also keeping the quirkiness
>> of being able to run a script synchronously while a node is removed, I'm
>> totally OK with that, but that needs to be a conscious decision.
>>
>>
>>>
>>> On Fri, Mar 29, 2024 at 5:28 AM Domenic Denicola 
>>> wrote:
>>>


 On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal 
 wrote:

> Contact emailsnrosent...@chromium.org, d...@chromium.org
>
> ExplainerNone
>

 A few paragraphs, including e.g. example code and how it behaves
 differently before/after the change, would help clarify this for web
 developers.

>>>
>> Sure!
>> Writing those here, if you think they need to be in some repo that's fine.
>> This will mainly affect code that uses global `focus` `blur` event
>> listeners to track the active element, for example in a form:
>>
>> ```js
>> form.addEventListener("focus", () => { trackActiveElementChange() }, {
>> capture: true});
>> form.addEventListener("blur", () => { trackActiveElementChange() },
>> {capture: true});
>> ```
>>
>> Now, since the active element might be removed without a `blur` event,
>> the same can be achieved with mutation observers:
>> ```js
>> form.addEventListener("focus", () => { trackActiveElementChange() }, {
>> capture: true});
>> new MutationObserver(entries => {
>>   if (Array.from(entries).some(entry => entry.removedNodes.length)
>>  trackActiveElementChange();
>> }).observe(form);
>> ```
>>
>> In essence the author can check that the node either lost focus or was
>> removed, but you don't have an event that tells you that "either" happened.
>> So all the use cases can be covered, but of course there is a backwards
>> compat risk as mentioned in this thread. We should make a decision on how
>> to go forward as a balance between the backwards-compat risk and the
>> other-browser-compat risk.
>>
>> This is done as part of an effort to see if we can get rid of (as many as
>> possible) scripts that can run in the middle of a DOM operation.
>> This one and events on iframe removal are the only ones remaining.
>>
>
> To provide a little more context - activeElement tracking is used heavily
> by most webapp having non-trivial a11y implementations.
>
> An example of this pattern is something like:
>
> https://github.com/tridactyl/tridactyl/blob/f49e1c94bcd481fdc86fb219335bafc4ce0f25ab/src/content.ts#L180-L187
> (From the first page of a github search of activeElement + setInterval).
> (Above is for a Firefox specific extension I think - so doesn't have any
> if (FIREFOX) for the interval checking).
> (Not this case exactly also - but same pattern).
>
> setInterval checking is done for other browsers as there isn't a great way
> to check for activeElement changes (maybe there should be async events? -
> but thats a separate discussion).
> But web developers might have only done the setInterval pattern for
> Firefox/Safari.
>
> Ian
>
> --
>> 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/CAJn%3DMYbiys600Gk5c%3DsW8B-iJOzRHqWq6Puc5nm8f-78zvxJvw%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 

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

[Ian Kilpatrick]

On Fri, Mar 29, 2024 at 4:33 AM Noam Rosenthal 
wrote:

>
>
> On Fri, Mar 29, 2024 at 6:33 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> On top of Domenic's questions, have we tried to estimate the risk here?
>> Even if it's Chromium-only, there could be Enterprise or embedded scenarios
>> that somehow rely on it.
>>
> Yes, and we're willing to keep the old behavior as an enterprise policy,
> at least temporarily.
>
>
>> Do we know how often this blur event actually fires?
>>
>
> There's no way to find out unfortunately. This event is currently fired
> for every removal, and there could be event listeners that handle it, but
> there is no way to tell if functionality builds on it, or at least I
> couldn't think of one (happy for suggestion). We wanted to disable it in a
> finch and If we decide that we would rather leave things as is, staying
> incompatible with Gecko/WebKi/the standard, and also keeping the quirkiness
> of being able to run a script synchronously while a node is removed, I'm
> totally OK with that, but that needs to be a conscious decision.
>
>
>>
>> On Fri, Mar 29, 2024 at 5:28 AM Domenic Denicola 
>> wrote:
>>
>>>
>>>
>>> On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal 
>>> wrote:
>>>
 Contact emailsnrosent...@chromium.org, d...@chromium.org

 ExplainerNone

>>>
>>> A few paragraphs, including e.g. example code and how it behaves
>>> differently before/after the change, would help clarify this for web
>>> developers.
>>>
>>
> Sure!
> Writing those here, if you think they need to be in some repo that's fine.
> This will mainly affect code that uses global `focus` `blur` event
> listeners to track the active element, for example in a form:
>
> ```js
> form.addEventListener("focus", () => { trackActiveElementChange() }, {
> capture: true});
> form.addEventListener("blur", () => { trackActiveElementChange() },
> {capture: true});
> ```
>
> Now, since the active element might be removed without a `blur` event, the
> same can be achieved with mutation observers:
> ```js
> form.addEventListener("focus", () => { trackActiveElementChange() }, {
> capture: true});
> new MutationObserver(entries => {
>   if (Array.from(entries).some(entry => entry.removedNodes.length)
>  trackActiveElementChange();
> }).observe(form);
> ```
>
> In essence the author can check that the node either lost focus or was
> removed, but you don't have an event that tells you that "either" happened.
> So all the use cases can be covered, but of course there is a backwards
> compat risk as mentioned in this thread. We should make a decision on how
> to go forward as a balance between the backwards-compat risk and the
> other-browser-compat risk.
>
> This is done as part of an effort to see if we can get rid of (as many as
> possible) scripts that can run in the middle of a DOM operation.
> This one and events on iframe removal are the only ones remaining.
>

To provide a little more context - activeElement tracking is used heavily
by most webapp having non-trivial a11y implementations.

An example of this pattern is something like:
https://github.com/tridactyl/tridactyl/blob/f49e1c94bcd481fdc86fb219335bafc4ce0f25ab/src/content.ts#L180-L187
(From the first page of a github search of activeElement + setInterval).
(Above is for a Firefox specific extension I think - so doesn't have any if
(FIREFOX) for the interval checking).
(Not this case exactly also - but same pattern).

setInterval checking is done for other browsers as there isn't a great way
to check for activeElement changes (maybe there should be async events? -
but thats a separate discussion).
But web developers might have only done the setInterval pattern for
Firefox/Safari.

Ian

-- 
> 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/CAJn%3DMYbiys600Gk5c%3DsW8B-iJOzRHqWq6Puc5nm8f-78zvxJvw%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/CAJL3UpTXrcMY3aTEzSeN-po%2Bqz3nthQ9cgj4tkGovBo%3DL5x9JA%40mail.gmail.com.

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

[Noam Rosenthal]

On Fri, Mar 29, 2024 at 6:33 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> On top of Domenic's questions, have we tried to estimate the risk here?
> Even if it's Chromium-only, there could be Enterprise or embedded scenarios
> that somehow rely on it.
>
Yes, and we're willing to keep the old behavior as an enterprise policy, at
least temporarily.


> Do we know how often this blur event actually fires?
>

There's no way to find out unfortunately. This event is currently fired for
every removal, and there could be event listeners that handle it, but there
is no way to tell if functionality builds on it, or at least I couldn't
think of one (happy for suggestion). We wanted to disable it in a finch and
If we decide that we would rather leave things as is, staying incompatible
with Gecko/WebKi/the standard, and also keeping the quirkiness of being
able to run a script synchronously while a node is removed, I'm totally OK
with that, but that needs to be a conscious decision.


>
> On Fri, Mar 29, 2024 at 5:28 AM Domenic Denicola 
> wrote:
>
>>
>>
>> On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal 
>> wrote:
>>
>>> Contact emailsnrosent...@chromium.org, d...@chromium.org
>>>
>>> ExplainerNone
>>>
>>
>> A few paragraphs, including e.g. example code and how it behaves
>> differently before/after the change, would help clarify this for web
>> developers.
>>
>
Sure!
Writing those here, if you think they need to be in some repo that's fine.
This will mainly affect code that uses global `focus` `blur` event
listeners to track the active element, for example in a form:

```js
form.addEventListener("focus", () => { trackActiveElementChange() }, {
capture: true});
form.addEventListener("blur", () => { trackActiveElementChange() },
{capture: true});
```

Now, since the active element might be removed without a `blur` event, the
same can be achieved with mutation observers:
```js
form.addEventListener("focus", () => { trackActiveElementChange() }, {
capture: true});
new MutationObserver(entries => {
  if (Array.from(entries).some(entry => entry.removedNodes.length)
 trackActiveElementChange();
}).observe(form);
```

In essence the author can check that the node either lost focus or was
removed, but you don't have an event that tells you that "either" happened.
So all the use cases can be covered, but of course there is a backwards
compat risk as mentioned in this thread. We should make a decision on how
to go forward as a balance between the backwards-compat risk and the
other-browser-compat risk.

This is done as part of an effort to see if we can get rid of (as many as
possible) scripts that can run in the middle of a DOM operation.
This one and events on iframe removal are the only ones remaining.

-- 
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/CAJn%3DMYbiys600Gk5c%3DsW8B-iJOzRHqWq6Puc5nm8f-78zvxJvw%40mail.gmail.com.

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

[Yoav Weiss (@Shopify)]

On top of Domenic's questions, have we tried to estimate the risk here?
Even if it's Chromium-only, there could be Enterprise or embedded scenarios
that somehow rely on it.
Do we know how often this blur event actually fires?

On Fri, Mar 29, 2024 at 5:28 AM Domenic Denicola 
wrote:

>
>
> On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal 
> wrote:
>
>> Contact emailsnrosent...@chromium.org, d...@chromium.org
>>
>> ExplainerNone
>>
>
> A few paragraphs, including e.g. example code and how it behaves
> differently before/after the change, would help clarify this for web
> developers.
>
>
>>
>>
>> Specificationhttps://html.spec.whatwg.org/#dom-trees:event-blur
>>
>> Summary
>>
>> Currently Chromium-based browsers are the only ones that fire blur events
>> when an element is removed from the DOM. This has recently been clarified
>> in the spec. As part of an effort to reduce synchronous side-effects of DOM
>> insertion & removal, this deprecation will cautiously test the impact and
>> feasibility of aligning with the spec/other browsers on this.
>>
>>
>> Blink componentBlink>DOM
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> There is no new API here, only a change to an existing behavior.
>>
>>
>> Activation
>>
>> N/A
>>
>>
>> Security
>>
>> Shouldn't be applicable.
>>
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes
>>
>>
>> https://wpt.fyi/results/dom/nodes/insertion-removing-steps/blur-event.window.html?label=experimental=master
>>
>>
>> Flag name on chrome://flagsOmitBlurEventOnElementRemoval
>>
>> Finch feature nameOmitBlurEventOnElementRemoval
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://g-issues.chromium.org/issues/41484175
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>
> Can you specify what milestones you are planning to deprecate for, and
> what milestone you are planning to remove in?
>
>
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5128696823545856?gate=5183419526152192
>>
>> 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/CAJn%3DMYZqb%2BD4BEuaK4HzAAy7Td6QvJZhhOuWGH3a9SHyGKMUyQ%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/CAM0wra9a5fLM%3DSiOkq0xmrovf2ZANwDncBQjO0BKWvoxzFQNJg%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/CAOmohSJGv6HC5Nd3g9b5h%2BDharPeorqRbramricgL91b05a8wQ%40mail.gmail.com.

Re: [blink-dev] Intent to deprecate and remove: Stop sending blur events on element removal

[Domenic Denicola]

On Fri, Mar 29, 2024 at 2:33 AM Noam Rosenthal 
wrote:

> Contact emailsnrosent...@chromium.org, d...@chromium.org
>
> ExplainerNone
>

A few paragraphs, including e.g. example code and how it behaves
differently before/after the change, would help clarify this for web
developers.


>
>
> Specificationhttps://html.spec.whatwg.org/#dom-trees:event-blur
>
> Summary
>
> Currently Chromium-based browsers are the only ones that fire blur events
> when an element is removed from the DOM. This has recently been clarified
> in the spec. As part of an effort to reduce synchronous side-effects of DOM
> insertion & removal, this deprecation will cautiously test the impact and
> feasibility of aligning with the spec/other browsers on this.
>
>
> Blink componentBlink>DOM
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> There is no new API here, only a change to an existing behavior.
>
>
> Activation
>
> N/A
>
>
> Security
>
> Shouldn't be applicable.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/dom/nodes/insertion-removing-steps/blur-event.window.html?label=experimental=master
>
>
> Flag name on chrome://flagsOmitBlurEventOnElementRemoval
>
> Finch feature nameOmitBlurEventOnElementRemoval
>
> Requires code in //chrome?False
>
> Tracking bughttps://g-issues.chromium.org/issues/41484175
>
> Estimated milestones
>
> No milestones specified
>

Can you specify what milestones you are planning to deprecate for, and what
milestone you are planning to remove in?


>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5128696823545856?gate=5183419526152192
>
> 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/CAJn%3DMYZqb%2BD4BEuaK4HzAAy7Td6QvJZhhOuWGH3a9SHyGKMUyQ%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/CAM0wra9a5fLM%3DSiOkq0xmrovf2ZANwDncBQjO0BKWvoxzFQNJg%40mail.gmail.com.