New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 674219 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

OOPIF: tab traversal doesn't escape OOPIF if main frame previously had an active element after it

Project Member Reported by aval...@chromium.org, Dec 14 2016

Issue description

Chrome Version: ToT

Repro:
1. Ensure go to http://csreis.github.io/tests/cross-site-iframe-simple.html
with --site-per-process
2. In devtools, add an input field: document.body.appendChild(document.createElement("input"))
3. click on the new <input>
4. click on an <input> in the OOPIF, then keep tabbing. When reaching
the end, focus should shift to the new <input> in the main frame, but
instead it wraps back into the OOPIF.

What is the expected result?
The new input is reachable with tab navigation.

What happens instead?
Tab navigation gets trapped in the iframe.
 
Labels: -OS-Linux OS-All
Summary: OOPIF: tab traversal doesn't escape OOPIF if main frame previously had an active element after it (was: OOPIF: )
For reference, this was discovered in a code review on https://codereview.chromium.org/2474323002/diff/60001/content/browser/web_contents/web_contents_view_child_frame.cc#newcode155.  avallee@: this also affects <webview>, right?
With a bit of investigating this only happens when the frame focus change is not initiated by the embedding renderer. Also, if there is not focused element in the embedder, the activeElement correctly becomes the iframe.
The same thing happens in OOPIF <webiew>.
Cc: wjmaclean@chromium.org lfg@chromium.org
 Issue 699635  has been merged into this issue.
Owner: aval...@chromium.org
Status: Started (was: Available)
Here's a similar bug that involves a focused element in the subframe instead of the main frame:

1. Go to http://csreis.github.io/tests/cross-site-iframe-simple.html with
--site-per-process.
2. In devtools, 
document.querySelector("h1").appendChild(document.createElement("input"))
3. Click first <input> in iframe
4. Click the main frame's <input> created in step 2.
5. Press tab

Focus should switch to the first <input> in the iframe, but instead it
shifts to the *second* <input> there.
I was wondering why my test was failing. There is a double advancement there.
Project Member

Comment 8 by bugdroid1@chromium.org, May 11 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9edd151ead7afa9dc3f8cb3f4620adf949eb119c

commit 9edd151ead7afa9dc3f8cb3f4620adf949eb119c
Author: avallee <avallee@chromium.org>
Date: Thu May 11 07:04:51 2017

<webview>: Add test to confirm the TAB key will escape the view.

There is a corner case where the embedder may think the element directly
following the webview has focus prevents focusing moving out of the
webview with the tab key.

This problem is a combination of the embedder not knowing the webview is
focused and some early out logic when landing on the next element
because it is already focused.

BUG= 674219 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2732913005
Cr-Commit-Position: refs/heads/master@{#470855}

[modify] https://crrev.com/9edd151ead7afa9dc3f8cb3f4620adf949eb119c/chrome/browser/apps/guest_view/web_view_interactive_browsertest.cc
[modify] https://crrev.com/9edd151ead7afa9dc3f8cb3f4620adf949eb119c/chrome/test/data/extensions/platform_apps/web_view/focus/embedder.js
[add] https://crrev.com/9edd151ead7afa9dc3f8cb3f4620adf949eb119c/chrome/test/data/extensions/platform_apps/web_view/focus/inject_focus_take_focus.js

Status: Fixed (was: Started)

Sign in to add a comment