[webkit-dev] focusin/focusout events

Darin Adler darin at apple.com
Mon Jul 26 00:06:58 PDT 2010


On Jul 21, 2010, at 5:24 PM, Ojan Vafai wrote:

> Opera 10.6: blur, domfocusout, focus, domfocusin 
> Moves activeElement immediately before firing any events.
> 
> WebKit nightly: blur, (dom)focusout, focus, (dom)focusin
> Clears activeElement before blur/focusout, sets active element before focus/focusin
> 
> FF 3.6:blur, focus
> Clears activeElement before blur, sets active element before focus.
> 
> IE 8: focusout, focusin, blur, focus
> Moves activeElement immediately before firing any events.

You mention activeElementId, but there must be other side effects that matter.

> It's a bit gross, but the only solution I can think of is to fire the following events in WebKit (in this order):
> focusout
> focusin
> {remove focus and clear selection as appropriate}
> blur
> domfocusout
> {add focus to new node and set selection as appropriate}
> focus
> domfocusin

This sequence doesn’t sound too terrible to me. But I don’t fully understand the proposal. At the time the focusin event fires we won’t yet know what item is getting focus? Is the design that the focusin event’s target knows it will be getting focused? What about focus changes that come about along with selection changes? Or is there no such thing?

Sounds like some differences are:

    1) The blur event in Opera and IE will see the new focused node as the active element, but in WebKit and Firefox will see no active element at all.
    2) Same for DOMFocusOut, but IE and Firefox are not affected.

Is there a good reason to do blur the Firefox way instead of the Opera/IE way? Maybe because it’s the legacy WebKit way, and hence likely to be depended on by WebKit-tested or WebKit/Firefox-tested content?

    -- Darin



More information about the webkit-dev mailing list