Pseudo-Class :focus :focus-within does not match if iframes are selected
Reported by
christop...@gmail.com,
Dec 1
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 Steps to reproduce the problem: Check http://jsfiddle.net/9dtyj1zk/2/ and click/tab through the elements. What is the expected behavior? :focus and :focus-within applies to iframes/parentNodes if the user is active in them. What went wrong? Clicking inside an iframe doesn't set the focus to this element, also it's parents won't apply the :focus-within. Did this work before? No Does this work in other browsers? No Firefox 63 acts equal to chrome and doesn't apply the selectors. Edge 17 ignores focus-within completly. Chrome version: 70.0.3538.110 Channel: stable OS Version: 10.0 Flash Version: iframes should get the :focus like input or other similar element types as it is requested by the specs. See https://html.spec.whatwg.org/multipage/interaction.html#focusable-area and https://drafts.csswg.org/selectors-4/#the-focus-within-pseudo
,
Dec 3
Unable to reproduce the issue on reported chrome version #70.0.3538.110 using Windows 10 by following below steps: Steps: ===== 1.Launched chrome. 2.Navigated to "http://jsfiddle.net/9dtyj1zk/2/" 3.click/Tab through the elements 4.Clicking on iframes able to set the focus Attached screencast for reference. @reporter: Could you please review attached screencast and let us know if anything is being missed here. Requesting you to check the issue by creating a new person without any apps and extensions in it, reset all flags to default and let us know if it still persists. Thanks.!
,
Dec 3
Iframes aren't like other elements, this is working as intended and is compatible with other browsers.
,
Dec 5
As stated in the HTML standard Data Model 6.4.2: (from https://html.spec.whatwg.org/multipage/interaction.html#focusable-area) ------- The term focusable area is used to refer to regions of the interface that can become the target of keyboard input. ... Elements that have their tabindex focus flag set, that are not actually disabled, that are not expressly inert, and that are either being rendered or being used as relevant canvas fallback content. iframe, <input type=text>, sometimes <a href=""> (depending on platform conventions). ------- An iframe is a focusable area which should apply the :focus or at least :focus-within pseudo class, if the user interacts inside them. As written in https://drafts.csswg.org/selectors-4/#the-focus-within-pseudo you can read 'any' and not 'except iframe'. Every iframe that is visible/rendered fulfills the requirements for them. I don't see any reason, why iframe elements and elements above shouldn't get the focus(-within) classes applied. As you can do it already on your own with a search for document.activeElement. They even allow autofocus to be defined. They differ in no way (for focus handling) from input fields. The descriptions on every doc, refer to iframes as some kind of input field. Even tho they load different content. See also - https://developer.mozilla.org/en-US/docs/Web/CSS/:focus - https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-within Greetings |
|||
►
Sign in to add a comment |
|||
Comment 1 by phanindra.mandapaka@chromium.org
, Dec 1