New issue
Advanced search Search tips

Issue 736733 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug



Sign in to add a comment

Focusing something outside of an iframe sets document.activeElement to the iframe <body> element

Reported by stol...@gmail.com, Jun 26 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36

Steps to reproduce the problem:
1. Have a website with an iframe.
2. Focus element A in the iframe.
3. Focus something outside of the iframe.

What is the expected behavior?
document.activeElement inside of the iframe is not changed (still element A).

What went wrong?
document.activeElement within the iframe is set to the iframe's body instead of not being changed and still being element A.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 58.0.3029.81  Channel: n/a
OS Version: 
Flash Version: 

Firefox implements this as I would expect it.
 

Comment 1 Deleted

Comment 2 by woxxom@gmail.com, Jun 26 2017

Repro:
0. download and open the attached test.html
1. click the text area with "1. click me"
2. click the button with "2. now click me"

EXPECTED: "iframe active element inside is: TEXTAREA, STATUS: SUCCESS"
OBSERVED: "iframe active element inside is: BODY, STATUS: FAIL"

Chrome 31 fails so it's not a regression.
IE 11 fails.
Edge fails.

Firefox 56 succeeds.

==============

Someone who is proficient at reading the specifications will weigh in on this.
Right now I'm not sure Firefox is the one that implements the specification correctly.

https://html.spec.whatwg.org/multipage/interaction.html#dom-document-activeelement
>4. If candidate is a focusable area, let candidate be candidate's DOM anchor.
>5. If candidate is a Document that has a body element, then let candidate be the body element of that Document.

When an iframe is not focused, is its contents still a "focusable area"? Currently Chrome/IE/Edge/whatnot behave like it's not, probably because iframe's "document" doesn't have a "browsing context", so step 5 is executed.
test.html
1016 bytes View Download
Labels: Needs-Triage-M59 Needs-Bisect
Labels: -Needs-Bisect -Needs-Triage-M59 M-61 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Linux Ubuntu 14.04,Mac 10.12.5 & Windows 7 using chrome reported version#58.0.3029.81 ,latest stable#59.0.3071.115 & Canary#61.0.3141.0 as per the above attached html file in comment#2.

Observed Iframe element as 'Body' & Status as 'FAIL' from M30 builds onwards. As this is non regression issue,marking it as 'Untriaged' to get more inputs from dev.

Note: On Ubuntu,observed the same behaviour from M47 builds. Observed crash when we install earlier builds of M47.

Please find the attached screen shot of Linux for reference.

Thanks.

736733.png
116 KB View Download

Comment 5 by tkent@chromium.org, Jun 29 2017

Components: -Blink>HTML Blink>Focus

Comment 6 by kochi@chromium.org, Jul 18 2017

Cc: kochi@chromium.org
Status: Available (was: Untriaged)
Components: Blink>HTML>Focus
Components: -Blink>Focus
Project Member

Comment 9 by sheriffbot@chromium.org, Oct 1

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Cc: -kochi@chromium.org
Labels: -Pri-2 -Hotlist-Recharge-Cold Pri-3
Status: Available (was: Untriaged)

Sign in to add a comment