- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Fri, 10 Jan 2014 21:09:29 +0000
- To: "ian@hixie.ch" <ian@hixie.ch>, "olli@pettay.fi" <olli@pettay.fi>
- CC: "public-html@w3.org" <public-html@w3.org>
- Message-ID: <add27a5c13fe4bfd85d2bc67926a1f29@BLUPR03MB344.namprd03.prod.outlook.com>
Just got a pretty serious bug report today for a Facebook scenario that hangs IE. In looking into the issue, the root cause appears to be a difference in how IE handles setting focus on a child browsing context's browsing context container which is different than how Firefox and Chrome handle it. The relevant spec text is in Section 7.4 Focus: "When a child browsing context is focused, its browsing context container must also have focus." And further down in a note in Section 7.4.3 Document-level focus APIs: "Note: When a child browsing context is focused, its browsing context container is also focused, by definition. For example, if the user moves the focus to a text field in an iframe, the iframe is the element with focus in the parent browsing context." In the scenario above (re-created in the attached test), IE fires DOM focus events on the browsing context container when something inside it's child browsing context is focused. Firefox nor Chrome appear to do this (and for this reason the Facebook bug doesn't impact them). In this scenario, all the browsers I tested set the activeElement of the parent browsing context to the browsing context container of the child browsing context. It's just that this is done silently relative to DOM events firing for the parent browsing context. I would love a little help in understanding where Firefox/Chrome are deriving their behavior from in the spec. My best guess is that their behavior could be derived from the requirements in Section 7.4.4 Element-level focus APIs, where it says to mark an element "locked for focus" as part of the focus() method algorithm. If the act of attempting to set the browsing context container active is running up against this "focus lock" than the focus DOM events would naturally be suppressed. This reading of the spec seems like a bit of a stretch though, since blur events are not fired either. Also, I'm not sure how to interpret step 3 of the focusing steps for an element. Is it related? "Make the element the currently focused element in its top-level browsing context." What is the intent behind this requirement; is it only relevant to user agents that track focus only for one element per top-level browsing context? -Travis
Attachments
- text/html attachment: eventTest.htm
Received on Friday, 10 January 2014 21:09:59 UTC