You need to
before you can comment on or make changes to this bug.
The focusin event doesn't fire if you blur and refocus an iframe with an editable body by clicking on the documentElement. This breaks input method on Safari Mac and causes script issues since the body has editing focus but the events never fired so you can't detect that the body is properly focused.
Steps to reproduce:
1. Open the attached URL
2. Click inside the green area (body)
3. Click outside the iframe in the white area (parent document)
4. Click inside the red area (documentElement)
5. Observe that the focus event only fired for the first click inside the iframe also notice that the focus even will fire once you enter a character.
The focusin should fire and the body should have proper focus.
The focusin event never fires when you refocus the document by clicking the documentElement.
Created an attachment (id=136531) [details]
Also added a case where contentEditable is on the html element, which does what the reporter expects.
Created an attachment (id=136532) [details]
better test case
In this test case, there are three cases:
1. No editable content.
2. The body element is editable.
3. The html element is editable.
Only fires focus/blur events. Fires them when clicking both the html element and the body element for all cases 1, 2 and 3.
Chrome 19 dev channel (basically WebKit tip of tree):
1. No events fired.
2. focusin and DOMFocusIn fired only when clicking on the body element and corresponding focusout/DOMFocusOut when clicking away.
3. focusin and DOMFocusIn fired when clicking on the body element or the html element and corresponding focusout/DOMFocusOut when clicking away.
1. No events fired.
2. focusin and DOMFocusIn fired only when clicking on the body element and corresponding focusout/DOMFocusOut when clicking away. Also get focusOut/DOMFocusOut when clicking away from the html element.
3. No focusin/DOMFocusIn events fired. focusout/DOMFocusOut get fired when clicking away.
Created an attachment (id=136536) [details]
use capture phase for event listeners
(In reply to comment #3)
> Chrome 19 dev channel (basically WebKit tip of tree):
> 1. No events fired.
> 2. focusin and DOMFocusIn fired only when clicking on the body element and corresponding focusout/DOMFocusOut when clicking away.
> 3. focusin and DOMFocusIn fired when clicking on the body element or the html element and corresponding focusout/DOMFocusOut when clicking away.
When using capture phase listeners, WebKit also fires focus/blur in all cases where it fires focusin/focusout.
Created an attachment (id=136539) [details]
standards mode, capture phase test case
IE9/10 standards mode:
For all cases, fires focusin/focusout and blur/focus.
The relevant spec for this doesn't really say what to do for the document itself: http://www.w3.org/TR/DOM-Level-3-Events/#events-focusevent-doc-focus.
WebKit's behavior seems correct to me for the body/html elements. They are focusable only if something makes them focusable (e.g. contentEditable). But, I think WebKit's behavior is less sensible for the document itself. In a sense, the document is always focusable (e.g. you can focus it's window).
In short, I think we should match IE here and fire these events on the document.
I found this bug when working on a bug fix for input method. It seems that when you focusin then focusout and focusin again by clicking on the documentElement the focus event doesn't get passed to the input method logic so if you type Japaneese for example the first letter won't be converted. I guess I could report a separate bug for that issue since it seems related but it involved a lot more steps to reproduce.
Created an attachment (id=136542) [details]
attach listeners to the document and the documentElement
Sigh. More inconsistency. With both the document and documentElement focusable:
Do the same thing. They fire focus events on the document iff they fire them on the documentElement.
1. If there's nothing editable, only fires focus/blur on the document.
2/3. If the body or the html element is editable, fire focus/blur on the document and the documentElement.
In all cases, fire all focus-related events on both the document and the documentElement.
The IE behavior still makes the most sense to me, although, I could believe arguments for the Gecko behavior.
Created an attachment (id=136545) [details]
attach listeners to the body as well
www-dom discussion: http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0029.html
The HTML spec tries to spec focus events; does it answer the question you have here?