New issue
Advanced search Search tips

Issue 639332 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment

Race condition in web view accessibility

Project Member Reported by dmazz...@chromium.org, Aug 19 2016

Issue description

When a WebView is initially created / loaded, there's a race condition where it might not be properly attached to the parent frame until after it updates or gets focus.

The user-observed behavior is that they open something with a WebView inside using a screen reader, the screen reader "skips over" the WebView when using screen reader navigation keys, but once they press Tab and put focus inside the WebView it starts working normally.

One specific repro:

- Get a Chromebook with ARC support and enable it, but with Play Store initially off. Or test locally by running Chrome with chromeos=1 and --enable-arc and --login-manager

- Turn on spoken feedback (Ctrl+Alt+Z)

- In settings, enable play store

- This pops up a dialog. On the TOS screen, click the "Agree" button.

- On the next screen, it says "Sign in to Google Play on your Chrome OS device". Try to press ChromeVox navigation keys: either Search+Shift+Down/Up by default, or Search+Down/Up if you've enabled ChromeVox Next.

- What's supposed to happen is that ChromeVox will navigate to all of the text of the dialog, like the welcome, the "Sign in to Google Play on your Chrome OS device" text, and the Sign In button. The bug is that it doesn't, but it's flaky - it might work some of the time.

- If you press Tab to focus the Sign In button, then ChromeVox navigation will work

This is probably related to other bug reports involving web views - if a PDF or the Chrome sign in dialog were flaky this could be the cause.

 

Comment 1 Deleted

Comment 2 by gov...@chromium.org, Aug 19 2016

Moving to M54 per chat with dmazzoni@, I don't need to merge this to 53, just to 54. 
Confirmed, I meant to put M54

Comment 4 by ajha@chromium.org, Aug 23 2016

Friendly reminder:
We are approaching the M-54 branch in few days from now. Please prioritize this accordingly. 

Thank you!
Project Member

Comment 5 by bugdroid1@chromium.org, Aug 23 2016

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

commit fa0d26cbe289463f9bfcceee216d620aef3028af
Author: dmazzoni <dmazzoni@chromium.org>
Date: Tue Aug 23 22:15:39 2016

Fix two race conditions in web view accessibility

Add a new test for web view accessibility that ensures that when a web view
is loaded, the full composed accessibility tree always eventually appears
(spanning both the embedder and guest) even without any user events. The
previous tests first sent some sort of events (focus events or touch events)
to see that those worked; this test ensures that guest web contents are
accessible even before any events fire.

This exposed two race conditions:

1. If the accessibility tree for the embedder is built before the guest is
   attached, RFHI may not be able to map the browser plugin id to a guest
   at that point. The fix is for BrowserPlugin::Attach to post an update
   on its corresponding accessibility element.

2. If the accessibility tree for the guest is built before the embedder's,
   it won't have a parent accessible tree id. This causes a problem when
   the embedder accessibility tree is loaded because it references the guest
   as a child tree, but the child tree doesn't point back to its parent.
   The fix is to explicitly update the guest's accessibility tree data
   when its embedder's accessibility tree is loaded.

These races are covered by the test, but see bug for an end-user scenario.

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

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

[modify] https://crrev.com/fa0d26cbe289463f9bfcceee216d620aef3028af/chrome/browser/apps/guest_view/web_view_browsertest.cc
[modify] https://crrev.com/fa0d26cbe289463f9bfcceee216d620aef3028af/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/fa0d26cbe289463f9bfcceee216d620aef3028af/content/renderer/browser_plugin/browser_plugin.cc

Labels: Merge-Request-54

Comment 7 by dimu@chromium.org, Aug 24 2016

Labels: -Merge-Request-54 Merge-Review-54 Hotlist-Merge-Review
[Automated comment] Commit may have occurred before M54 branch point (8/25/2016), needs manual review.
Labels: -M-54 -Hotlist-Merge-review -ReleaseBlock-Stable -Merge-Review-54
Status: Fixed (was: Started)
No merge needed

Sign in to add a comment