Bug 83566 - Editable iframe doesn't get focusin event when clicking documentElement
: Editable iframe doesn't get focusin event when clicking documentElement
Status: NEW
: WebKit
HTML Editing
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
: http://www.tinymce.com/webkit/focus_i...
:
:
:
  Show dependency treegraph
 
Reported: 2012-04-10 05:28 PST by
Modified: 2012-06-11 16:07 PST (History)


Attachments
standalone test-case (1.26 KB, text/html)
2012-04-10 13:49 PST, Ojan Vafai
no flags Details
better test case (1.52 KB, text/html)
2012-04-10 13:52 PST, Ojan Vafai
no flags Details
use capture phase for event listeners (1.51 KB, text/html)
2012-04-10 14:03 PST, Ojan Vafai
no flags Details
standards mode, capture phase test case (1.53 KB, text/html)
2012-04-10 14:08 PST, Ojan Vafai
no flags Details
attach listeners to the document and the documentElement (2.26 KB, text/html)
2012-04-10 14:20 PST, Ojan Vafai
no flags Details
attach listeners to the body as well (2.73 KB, text/html)
2012-04-10 14:47 PST, Ojan Vafai
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-04-10 05:28:29 PST
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.
------- Comment #1 From 2012-04-10 13:49:33 PST -------
Created an attachment (id=136531) [details]
standalone test-case

Also added a case where contentEditable is on the html element, which does what the reporter expects.
------- Comment #2 From 2012-04-10 13:52:19 PST -------
Created an attachment (id=136532) [details]
better test case
------- Comment #3 From 2012-04-10 13:59:18 PST -------
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.
------- Comment #4 From 2012-04-10 14:03:30 PST -------
Created an attachment (id=136536) [details]
use capture phase for event listeners
------- Comment #5 From 2012-04-10 14:07:11 PST -------
(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.
------- Comment #6 From 2012-04-10 14:08:01 PST -------
Created an attachment (id=136539) [details]
standards mode, capture phase test case
------- Comment #7 From 2012-04-10 14:09:01 PST -------
IE9/10 standards mode:
For all cases, fires focusin/focusout and blur/focus.
------- Comment #8 From 2012-04-10 14:13:38 PST -------
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.
------- Comment #9 From 2012-04-10 14:17:35 PST -------
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.
------- Comment #10 From 2012-04-10 14:20:45 PST -------
Created an attachment (id=136542) [details]
attach listeners to the document and the documentElement
------- Comment #11 From 2012-04-10 14:29:41 PST -------
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.
------- Comment #12 From 2012-04-10 14:47:25 PST -------
Created an attachment (id=136545) [details]
attach listeners to the body as well
------- Comment #13 From 2012-04-10 14:56:44 PST -------
www-dom discussion: http://lists.w3.org/Archives/Public/www-dom/2012AprJun/0029.html
------- Comment #14 From 2012-06-11 16:07:56 PST -------
The HTML spec tries to spec focus events; does it answer the question you have here?