[webkit-dev] focusin/focusout events

[Erik Arvidsson]

I think the order as specced at
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-event-order
is fine. It seems to solve the ordering from a backwards compatibility
case.

The spec leaves out when document.activeElement is changed though.

erik



On Mon, Jul 26, 2010 at 18:32, Ojan Vafai <ojan at chromium.org> wrote:
> There are a few concerns on the table:
> 1. We don't match the DOM3 spec. I'm not too worried about this. Neither
> does anyone else. We could probably get the spec to change if noone is going
> to implement it as is.
> 2. We don't match other browsers. It's not clear to me what changes are
> worth making here.
> 3. There's no way to get the selection *before* an element is blurred.
> The third one is the only one I really care about solving, in the short term
> anyways. I'd like there to be a blur-like event that we fire *before*
> clearing the selection. With our current ordering of events, that would mean
> clearing the selection after the blur event or the focusout event or both,
> which no browser does. That said, it might be safe to just change this.
> Since no browser has a selection during the blur event and only IE has one
> during focusout, we might be able to get away with just changing that as
> noone should be depending on the selection at that point. Perhaps that's
> worth trying?
> On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler <darin at apple.com> wrote:
>>
>> You mention activeElementId, but there must be other side effects that
>> matter.
>
> The only other side effects I can think of are the focus outline (which
> could probably be tested via getComputedStyle?) and clearing the selection.
> In non-IE the selection isn't cleared if focus is moving across frames. But
> when focus moves within the same document, you get the following:
> IE 8: The selection is cleared after the focusout event and before focusin,
> blur, focus.
> WebKit && Opera: It's cleared before any events are fired.
> FF 3.6: It's cleared before any events are fired unless focus is moving to a
> textarea/input (not contentEditable!).
>
>>
>> > 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?
>
> I think we do know this and it wouldn't be too hard to implement. It's just
> a question of what we think the best behavior is. Specifically,
> in Document::setFocusedNode, we know both the new focused node and the old
> focused node when firing these events.
>
>>
>> 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.
>
> 3) IE fires focusout before the selection is cleared if the element being
> focused is the body (e.g. click from a contentEditable onto a non-focusable
> element).
>>
>> 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?
>
> My only concern was backwards compatibility, but I have no evidence that it
> is or isn't a valid concern.
> Ojan