ISSUE-102 (focus and focus()): Behavior of focus events when interacting with
focus()/blur() methods needs to be defined [DOM3 Events]
http://www.w3.org/2008/webapps/track/issues/102
Raised by: Doug Schepers
On product: DOM3 Events
Boris Zbarsky
wrote<http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0086.html>:
[[
Jacob Rossi wrote:
Yes, so in response to that action, here's how IE handles focus events:
focus, blur, focusin, and focusout can be registered on any element which is
"focusable."
During a focus change from elementA to elementB, the following events are
fired in this order:
1. focusout: srcElement is elementA, toElement is elementB, bubbles, not
cancelable
2. focusin: srcElement is elementB, fromElement is elementA, bubbles, not
cancelable
3. Focus changes from elementA to elementB
4. blur: srcElement is elementA, does not bubble, not cancelable
5. focus: srcElement is elementB, does not bubble, not cancelable
That's a great start (assuming we want to spec focusout/focusin). We
also need to spec what happens if a handler during any of steps 1, 2, 4,
5, calls focus() or blur() on some element (possible cases being
elementA, elementB, elementC). That's been by far the biggest source of
compatibility problems we've run into with Gecko.
]]
Jacob Rossi
wrote<http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0325.html>:
[[
On 9/15/09 4:21 PM, Travis Leithead wrote:
Do we really need eventTarget? It seems to me that focusin/focusout can remain UIEvents,
and if web developers want to know what the "releatedTarget" is, then can
simply register for both: focusout is the element loosing focus, focusin is the element
gaining focus. You don't even have to know which Node to register them on because these
events bubble, you can simply listen at the document level.
It's likely that one *could* solve this problem by listening to both.
But for complex systems it could get nasty simply because these events
don't fire concurrently.
In other words, for a single code path that needs to know both the
source and the destination of the focus change, your code would have
to save the target of the focusout event, wait for the focusin event,
and then proceed through the code path. While this is certainly
doable, it's much more elegant and straight forward to be able to just
grab both targets in during one event. (Also, see how the scenario
below might complicate this further.)
On Tue, Sep 15, 2009 at 4:02 PM, Doug Schepers<schep...@w3.org> wrote:
In fact, it's worth thinking about changing focusin and focusout to be
cancelable, to prevent the focus from changing. I doubt there is any
content that relies on them not being cancelable... what would people think
of this idea?
My last email (http://lists.w3.org/Archives/Public/www-dom/2009JulSep/0321.html)
had the wrong quote above it at the end. It was supposed to be the one
above. I was worried about the ability to trap focus. But I suppose
this is already possible with the ability to call focus() or blur().
This leads me to my next question:
What is the firing order when the focus is redirected during the focus
change (either if you can cancel the focusin event or by calling
focus( ) or blur() )? Example:
1. The focus is on element A
2. focusout fires on element A
3. focusin fires on element B Note: the focus hasn't actually changed yet.
3.1 A listener for focusin calls focus( ) on another element (element C)
At this point, which events fire and in what order?
I can see 2 possible options:
a) Simply redirect where the focus is going and fire the following events:
4. focusin on element C
5. Move focus to C
6. Blur on A
7. Focus on C
b) Assume that focus() effectively cause stopImmediatePropagation
to happen. Now start a new focus change:
4. focusout fires on element A
5. focusin fires on element C
6. Focus moves to C
7. Blur on A
8. Focus on C
Which option you pick could depend on whether the event object has a
relatedTarget on it. If it does not, then you can get away with option
(a) because there's no need to refire focusout on A because you'd
effectively be firing the same event your fired in step 2 again. If it
does, then you probably need option (b) because you need to fire
focusout with relatedTarget set to element C.
Furthermore, how does this order change if focus() is instead called
during a listener of the focusin event? during the blur event? during
the focus event?
]]
