Focus and focus()/blur() [ISSUE-102]

Hi, Folks-

I plan to tackle this issue soon.  If you have any thoughts about it, 
I'd appreciate your feedback before I get to it.

Please respond directly to this message, or send a message to www-dom 
with "[ISSUE-102]" in the subject line so Tracker finds it.

Thanks!

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Web Applications Working Group Issue Tracker wrote (on 9/22/09 3:08 AM):
>
> 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<schepers@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?
> ]]
>
>

Received on Tuesday, 22 September 2009 07:38:23 UTC