- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 10 Apr 2012 14:55:03 -0700
- To: www-dom@w3.org
- Message-ID: <CANMdWTs4VO-vdG_s6WhLxZuSbX+0UQ1zVOHakh27d2AiWcpM2w@mail.gmail.com>
http://www.w3.org/TR/DOM-Level-3-Events/#events-focusevent-doc-focus doesn't say whether to fire focus/blur-related events on the documentt/documentElement/body if nothing inside the document is focusable. Relevant WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=83566. Test case: https://bug-83566-attachments.webkit.org/attachment.cgi?id=136545 . There are three cases: 1. No editable content. 2. contentEditable (i.e. focusable) body element. 3. contentEditable (i.e. focusable) html element. In all browsers, in all three test cases, if you click on the documentElement or on the body element, document.activeElement points to the body element (and in the contentEditable cases, you get a blinking cursor inside the body element). Given that, I think focus events should fire on the document, documentElement and body elements in all three cases. This is the IE9+ behavior. -WebKit only does this if you click on a focusable element in the frame. -Opera does the WebKit behavior, except doesn't fire focusin/focus in some cases (looks like a bug since focusout/blur are fired). -Gecko fires only on the document itself if there are no focusable elements, but otherwise, does the IE behavior (Gecko only ever fires focus/blur though, no focusin/focusout). On the other hand, if script explicitly focuses the documentElement, then we should only fire focus-related events on the documentElement and the document, since document.activeElement actually points to the documentElement in that case. In short, to keep the platform sane, I think focus-related events should match how we set document.activeElement. Curious to hear what other browser vendors think before we change WebKit to match IE. Ojan
Received on Tuesday, 10 April 2012 21:55:54 UTC