Fix connection between BrowserAccessibilityManager and ContentViewCore

Fix connection between BrowserAccessibilityManager and ContentViewCore

In r380416, we switched to one accessibility tree per frame, whether site
isolation is on or not. On Android we only want the main frame's
BrowserAccessibilityManager to be connected to the ContentViewCore, not
any child frames.

I modified RWHVAndroid::CreateBrowserAccessibilityManager in that change so
that it wouldn't associate child frames with ContentViewCore, but I got my
logic flipped (in a way that made tests pass, but didn't work in practice).

In fixing it here, I realized that it may not be safe to assume that the
main frame is the first one to create a BrowserAccessibilityManager.
A more robust fix is for RFHI to pass a flag indicating whether it wants
a BAM for the main frame or for another frame.

In the future we may want to use that flag on other platforms, too - like
on Mac really only the main frame's BAM should have the cocoa_view_, but
I'll do that in a follow-up.

BUG=595150
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

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

[dmazzoni, 2016-03-16 18:35:38]

Description was changed from

==========
Fix connection between BrowserAccessibilityManager and ContentViewCore

In r380416, we switched to one accessibility tree per frame, whether site
isolation is on or not. On Android we only want the main frame's
BrowserAccessibilityManager to be connected to the ContentViewCore, not
any child frames.

I modified RWHVAndroid::CreateBrowserAccessibilityManager in that change so
that it wouldn't associate child frames with ContentViewCore, but I got my
logic flipped (in a way that made tests pass, but didn't work in practice).

In fixing it here, I realized that it may not be safe to assume that the
main frame is the first one to create a BrowserAccessibilityManager.
A more robust fix is for RFHI to pass a flag indicating whether it wants
a BAM for the main frame or for another frame.

In the future we may want to use that flag on other platforms, too - like
on Mac really only the main frame's BAM should have the cocoa_view_, but
I'll do that in a follow-up.

BUG=595150
==========

to

==========
Fix connection between BrowserAccessibilityManager and ContentViewCore

In r380416, we switched to one accessibility tree per frame, whether site
isolation is on or not. On Android we only want the main frame's
BrowserAccessibilityManager to be connected to the ContentViewCore, not
any child frames.

I modified RWHVAndroid::CreateBrowserAccessibilityManager in that change so
that it wouldn't associate child frames with ContentViewCore, but I got my
logic flipped (in a way that made tests pass, but didn't work in practice).

In fixing it here, I realized that it may not be safe to assume that the
main frame is the first one to create a BrowserAccessibilityManager.
A more robust fix is for RFHI to pass a flag indicating whether it wants
a BAM for the main frame or for another frame.

In the future we may want to use that flag on other platforms, too - like
on Mac really only the main frame's BAM should have the cocoa_view_, but
I'll do that in a follow-up.

BUG=595150
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

[dmazzoni, 2016-03-16 18:36:59]

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

[dcheng, 2016-03-17 05:53:19]

lgtm

[jam, 2016-03-17 23:02:34]

rubberstamp lgtm

[jam, 2016-03-17 23:02:50]

On 2016/03/17 23:02:34, jam wrote:
> rubberstamp lgtm

(i.e. can someone familiar with this code review instead of me?)

[dmazzoni, 2016-03-17 23:05:09]

I believe Daniel Cheng is familiar enough with this change.
If you feel this needs another reviewer let me know.

[dmazzoni, 2016-03-17 23:08:37]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2016-03-17 23:09:12]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1809793002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1809793002/20001

[commit-bot: I haz the power, 2016-03-18 00:16:55]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-03-18 00:18:43]

Description was changed from

==========
Fix connection between BrowserAccessibilityManager and ContentViewCore

In r380416, we switched to one accessibility tree per frame, whether site
isolation is on or not. On Android we only want the main frame's
BrowserAccessibilityManager to be connected to the ContentViewCore, not
any child frames.

I modified RWHVAndroid::CreateBrowserAccessibilityManager in that change so
that it wouldn't associate child frames with ContentViewCore, but I got my
logic flipped (in a way that made tests pass, but didn't work in practice).

In fixing it here, I realized that it may not be safe to assume that the
main frame is the first one to create a BrowserAccessibilityManager.
A more robust fix is for RFHI to pass a flag indicating whether it wants
a BAM for the main frame or for another frame.

In the future we may want to use that flag on other platforms, too - like
on Mac really only the main frame's BAM should have the cocoa_view_, but
I'll do that in a follow-up.

BUG=595150
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation
==========

to

==========
Fix connection between BrowserAccessibilityManager and ContentViewCore

In r380416, we switched to one accessibility tree per frame, whether site
isolation is on or not. On Android we only want the main frame's
BrowserAccessibilityManager to be connected to the ContentViewCore, not
any child frames.

I modified RWHVAndroid::CreateBrowserAccessibilityManager in that change so
that it wouldn't associate child frames with ContentViewCore, but I got my
logic flipped (in a way that made tests pass, but didn't work in practice).

In fixing it here, I realized that it may not be safe to assume that the
main frame is the first one to create a BrowserAccessibilityManager.
A more robust fix is for RFHI to pass a flag indicating whether it wants
a BAM for the main frame or for another frame.

In the future we may want to use that flag on other platforms, too - like
on Mac really only the main frame's BAM should have the cocoa_view_, but
I'll do that in a follow-up.

BUG=595150
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

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

[commit-bot: I haz the power, 2016-03-18 00:18:45]

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