Fix two race conditions in web view accessibility

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

Committed: https://crrev.com/fa0d26cbe289463f9bfcceee216d620aef3028af
Cr-Commit-Position: refs/heads/master@{#413857}

[dmazzoni, 2016-08-19 17:40:02]

Description was changed from

==========
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
==========

to

==========
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
==========

[dmazzoni, 2016-08-19 17:40:06]

The CQ bit was checked by dmazzoni@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-19 17:40:32]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[dmazzoni, 2016-08-19 17:45:36]

dmazzoni@chromium.org changed reviewers:
+ dcheng@chromium.org, fsamuel@chromium.org

[dmazzoni, 2016-08-19 17:45:36]

+dcheng: you're the most familiar with oopif / guest view a11y
+fsamuel: please review as you're the main owner for web_view
and browser_plugin

I'll ask for a content/ owner rubberstamp if Daniel and Fady are
happy

[dmazzoni, 2016-08-19 18:56:15]

dmazzoni@chromium.org changed reviewers:
+ dtseng@chromium.org

[dmazzoni, 2016-08-19 18:56:16]

+dtseng for review from the accessibility perspective

[dcheng, 2016-08-19 18:57:24]

dcheng@chromium.org changed reviewers:
- dtseng@chromium.org

[dcheng, 2016-08-19 18:57:25]

The change LGTM, but I'm not an expert.

[commit-bot: I haz the power, 2016-08-19 19:30:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-19 19:30:05]

Dry run: This issue passed the CQ dry run.

[Fady Samuel, 2016-08-23 13:01:35]

I'm not really sure I understand this change, but rs lgtm since you're the
expert.

[aboxhall, 2016-08-23 17:39:26]

aboxhall@chromium.org changed reviewers:
+ aboxhall@chromium.org

[aboxhall, 2016-08-23 17:39:26]

lgtm

[dmazzoni, 2016-08-23 17:41:01]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2016-08-23 17:41:23]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-23 17:49:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-23 17:49:03]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[dmazzoni, 2016-08-23 18:21:14]

dmazzoni@chromium.org changed reviewers:
+ sievers@chromium.org

[dmazzoni, 2016-08-23 18:21:14]

Oops, I need a content/ owner.

+sievers

[no sievers, 2016-08-23 20:48:50]

On 2016/08/23 18:21:14, dmazzoni wrote:
> Oops, I need a content/ owner.
> 
> +sievers

lgtm

[dmazzoni, 2016-08-23 21:13:14]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2016-08-23 21:14:02]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-23 22:16:13]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-08-23 22:19:56]

Description was changed from

==========
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
==========

to

==========
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

Committed: https://crrev.com/fa0d26cbe289463f9bfcceee216d620aef3028af
Cr-Commit-Position: refs/heads/master@{#413857}
==========

[commit-bot: I haz the power, 2016-08-23 22:19:57]

Patchset 1 (id:??) landed as
https://crrev.com/fa0d26cbe289463f9bfcceee216d620aef3028af
Cr-Commit-Position: refs/heads/master@{#413857}