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) <yoavwe...@chromium.org>
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 <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/CA%2B1LECSzpxUpbLg4jYwSBXj239qxW8EpvFbNCgrMBJgV41-vEQ%40mail.gmail.com.
