Bug 83566 – Editable iframe doesn't get focusin event when clicking documentElement

• Component: HTML Editing
• Status: NEW

[Johan "Spocke" Sörlin]

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.

Expected results:
The focusin should fire and the body should have proper focus.

Actual results:
The focusin event never fires when you refocus the document by clicking the documentElement.

[Ojan Vafai]

Created attachment 136531 [details]
standalone test-case

Also added a case where contentEditable is on the html element, which does what the reporter expects.

[Ojan Vafai]

Created attachment 136532 [details]
better test case

[Ojan Vafai]

In this test case, there are three cases:
1. No editable content.
2. The body element is editable.
3. The html element is editable.

Firefox 11:
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.

Opera 11.62:
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.

[Ojan Vafai]

Created attachment 136536 [details]
use capture phase for event listeners

[Ojan Vafai]

(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.

[Ojan Vafai]

Created attachment 136539 [details]
standards mode, capture phase test case

[Ojan Vafai]

IE9/10 standards mode:
For all cases, fires focusin/focusout and blur/focus.

[Ojan Vafai]

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.

[Johan "Spocke" Sörlin]

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.

[Ojan Vafai]

Created attachment 136542 [details]
attach listeners to the document and the documentElement

[Ojan Vafai]

Sigh. More inconsistency. With both the document and documentElement focusable:
WebKit/Opera:
Do the same thing. They fire focus events on the document iff they fire them on the documentElement.

Gecko:
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.

IE:
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.

[Ojan Vafai]

Created attachment 136545 [details]
attach listeners to the body as well

[Ojan Vafai]

www-dom discussion: http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0029.html

[Ian 'Hixie' Hickson]

The HTML spec tries to spec focus events; does it answer the question you have here?