Bug 83566 - Editable iframe doesn't get focusin event when clicking documentElement
Summary: Editable iframe doesn't get focusin event when clicking documentElement
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://www.tinymce.com/webkit/focus_i...
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-10 05:28 PDT by Johan "Spocke" Sörlin
Modified: 2017-07-18 08:30 PDT (History)
6 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Johan "Spocke" Sörlin 2012-04-10 05:28:29 PDT
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 Ojan Vafai 2012-04-10 13:49:33 PDT
Created attachment 136531 [details]
standalone test-case

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