focusin/focusout events
WebKit doesn't match the DOM 3 spec WRT focusin/focusout events, see http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event... . Specifically, focusin/focusout are supposed to fire before the element actually receives/loses focus. Browsers are wildly inconsistent with focus-related events, but only WebKit and IE support focusin/focusout and only WebKit gets this bit wrong. Also, there are a few things that you ought to be able to do that you can't currently: 1. Capture and handle a blur-type event before focus is moved or the selection is cleared/moved. 2. Capture and handle a focus-type event before focus is moved or the selection is cleared/moved. In WebKit, the selection and focus are cleared from the element being blurred before any events are fired. That's lametastic. One common use-case here is making keyboard-accessible UI widgets for a rich-text area. For keyboard-accessible UI widgets, especially ones that require text input (e.g. a font combo-box), you need to save the selection before blurring. Instead of simply listening to a blur event, you need to instrument every place that might clear the selection when clicked in order to save it first. I've listed below the order events are fired in different browsers when one element is blurred and another is focused. I was using roughly this code: <div contentEditable id=foo>asdf</div> <div contentEditable id=bar>qwer</div> <script> var foo = document.getElementById('foo'); var bar = document.getElementById('bar'); bar.addEventListener('DOMFocusIn', function() { console.log('focusin: ' + document.activeElement.id) }, true); bar.addEventListener('focus', function() { console.log('focus: ' + document.activeElement.id) }, true); foo.addEventListener('DOMFocusOut', function() { console.log('focusout: ' + document.activeElement.id) }, true); foo.addEventListener('blur', function() { console.log('blur: ' + document.activeElement.id) }, true); </script> 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. 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 I'd like to say we could get rid of DOMFocusOut/DOMFocusIn or blur/focus, but I expect too many sites would break. What do you all think? I care more about meeting the use-case listed above than matching the spec. If we can meet the above use-case differently, I expect we could get the spec modified. Ojan
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
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler <darin@apple.com> wrote:
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?
The spec seems to require that: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event... A user agent must dispatch this event when an event target loses focus. The focus shall be taken from the element before the dispatch of this event type. This event type is similar to focusout, but is dispatched after focus is shifted, and does not bubble. Best, Ryosuke
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@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
I think the order as specced at http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event... 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@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@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
On Jul 26, 2010, at 6:32 PM, Ojan Vafai wrote:
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler <darin@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.
Style changes specified using the :focus pseudo-style is another type of side effect.
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.
The “we” I meant is the JavaScript code on the webpage. -- Darin
On Tue, Jul 27, 2010 at 10:37 AM, Darin Adler <darin@apple.com> wrote:
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.
The “we” I meant is the JavaScript code on the webpage.
I see. I hadn't thought about this part. As per the current state of the DOM 3 spec for the target/relatedTarget event object: target relatedTarget blur/DOMFocusOut element losing focus element losing focus focus/DOMFocusIn element receiving focus element receiving focus focusin element receiving focus element losing focus focusout element losing focus element receiving focus The spec looks reasonable to me and I think we could implement it without worry about web compatibility since we would only be modifying the focusin/focusout events, which we just added recently. The only thing I'd like to change in the spec is that focusin/focusout are not cancelable, but that's a whole separate issue and something that should be addressed on www-dom first. Anyone object to that? Specifically, the proposal is to change our event order to match the spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event... to change the focusin/focusout events to have target/relatedTarget values as above. Ojan
participants (4)
-
Darin Adler
-
Erik Arvidsson
-
Ojan Vafai
-
Ryosuke Niwa