[webkit-dev] focusin/focusout events

[Ojan Vafai]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100726/e5790988/attachment.html>