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 <alevent...@google.com>
On Fri, Mar 29, 2024 at 7:01 PM Ian Kilpatrick <ikilpatr...@chromium.org>
wrote:
>
>
> On Fri, Mar 29, 2024 at 4:33 AM Noam Rosenthal <nrosent...@chromium.org>
> 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 <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.
>>
>
> 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
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbiys600Gk5c%3DsW8B-iJOzRHqWq6Puc5nm8f-78zvxJvw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/CAOmohS%2BbMoMFxstNWYabE2PGD-B3YK8ufTKZjN9dF9zJx5vkPA%40mail.gmail.com.
