WebKit doesn&#39;t match the DOM 3 spec WRT focusin/focusout events, see <a href="http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-doc-focus">http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-focusevent-doc-focus</a>. <meta charset="utf-8">Specifically, focusin/focusout are supposed to fire before the element actually receives/loses focus.<meta charset="utf-8"> Browsers are wildly inconsistent with focus-related events, but only WebKit and IE support focusin/focusout and only WebKit gets this bit wrong. <div>

<br></div><div>Also, there are a few things that you ought to be able to do that you can&#39;t currently:<div><div>1. Capture and handle a blur-type event before focus is moved or the selection is cleared/moved.</div><div>

2. Capture and handle a focus-type event before focus is moved or the selection is cleared/moved.</div><div><br></div><div><div>In WebKit, the selection and focus are cleared from the element being blurred before any events are fired. That&#39;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.</div>

</div><div><br></div><div><div>I&#39;ve listed below the order events are fired in different browsers when one element is blurred and another is focused.</div><div><br></div><div>I was using roughly this code:</div><div>
&lt;div contentEditable id=foo&gt;asdf&lt;/div&gt;</div>
<div>&lt;div contentEditable id=bar&gt;qwer&lt;/div&gt;</div><div>&lt;script&gt;</div><div>var foo = document.getElementById(&#39;foo&#39;);</div><div>var bar = document.getElementById(&#39;bar&#39;);</div><div>bar.addEventListener(&#39;DOMFocusIn&#39;, function() { console.log(&#39;focusin: &#39; + <a href="http://document.activeElement.id">document.activeElement.id</a>) }, true);</div>

<div>bar.addEventListener(&#39;focus&#39;, function() { console.log(&#39;focus: &#39; +<a href="http://document.activeElement.id">document.activeElement.id</a>) }, true);</div><div>foo.addEventListener(&#39;DOMFocusOut&#39;, function() { console.log(&#39;focusout: &#39; +<a href="http://document.activeElement.id">document.activeElement.id</a>) }, true);</div>

<div>foo.addEventListener(&#39;blur&#39;, function() { console.log(&#39;blur: &#39; +<a href="http://document.activeElement.id">document.activeElement.id</a>) }, true);</div><div>&lt;/script&gt;</div><div><br></div><div>
Opera 10.6: blur, domfocusout, focus, domfocusin </div>
<div>Moves activeElement immediately before firing any events.</div><div><br></div><div>WebKit nightly: blur, (dom)focusout, focus, (dom)focusin</div><div>Clears activeElement before blur/focusout, sets active element before focus/focusin</div>

<div><br></div><div>FF 3.6:blur, focus</div><div>Clears activeElement before blur, sets active element before focus.</div><div><br></div><div>IE 8: focusout, focusin, blur, focus</div><div>Moves activeElement immediately before firing any events.</div>

<div><br></div><div>It&#39;s a bit gross, but the only solution I can think of is to fire the following events in WebKit (in this order):</div><div>focusout</div><div>focusin</div><div>{remove focus and clear selection as appropriate}</div>

<div>blur</div><div>domfocusout</div><div>{add focus to new node and set selection as appropriate}</div><div>focus</div><div>domfocusin</div><div><br></div><div>I&#39;d like to say we could get rid of DOMFocusOut/DOMFocusIn or blur/focus, but I expect too many sites would break.</div>

</div><div><br></div></div></div><div>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.</div>

<div><br></div><div>Ojan</div>