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 <dome...@chromium.org>
> 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.
--
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.
