From Svet: The Chrome version in master generates loops in the a11y tree. Specifically, the host view (the one with the node provider) reports itself as its child. I put a break point at the addChild call on the node and indeed when the first node info is created (for the host) Chrome is adding a child with id -1 which is the id of the host. Is this a known issue?

Maybe related - should I have still returned false here? 

https://chromium-review.googlesource.com/c/chromium/src/+/863082/8/content/public/android/java/src/org/chromium/content/browser/ContentViewCoreImpl.java#1074

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

commit 39a4917789036b6fca7adf6ba637106160a844a0
Author: Jinsuk Kim <jinsukkim@chromium.org>
Date: Wed Jan 24 20:29:25 2018

Fix loop in accessibility

The API |CVC.performAccessibilityAction| had not been previously
implemented but accidentally hooked to the correspodning a11y method
in one of the refactoring efforts https://crrev.com/c/c863082.
This CL reverts it.

This cannot be the root cause of the reported bug since the bug predates
the culprit CL. But makes sense to link to it since it is related.

Bug:  805014 
Change-Id: Ib8065bd89a551397a4e1249f1bd448872c7a71a8
Reviewed-on: https://chromium-review.googlesource.com/882525
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531663}
[modify] https://crrev.com/39a4917789036b6fca7adf6ba637106160a844a0/content/public/android/java/src/org/chromium/content/browser/ContentViewCoreImpl.java
[modify] https://crrev.com/39a4917789036b6fca7adf6ba637106160a844a0/content/public/android/java/src/org/chromium/content/browser/accessibility/WebContentsAccessibility.java

Bisect with the reproduction step above points to this CL: https://chromium-review.googlesource.com/c/chromium/src/+/729145

Is this now fixed with #4?

As per ibobra@, This issue is not fixed yet.

If the bisect is correct, the bug is present in M64, which is already in stable.

I don't see much point in blocking the M65 beta if that's the case.

Let's mark it as a stable blocker for M65 and try to fix it for the second beta push.

Moving to RBS, as per c#8.  Please fix soon  Thanks.

Created a fix https://chromium-review.googlesource.com/c/chromium/src/+/891941 and verified that its working fine with S2S as well as uiautomatorviewer.

ping, how's that code review going?

Trying to make amend AwContentsGarbageCollectionTest#testAccessibility so that it passes. Will push it in soon.

Was this bug introduced in the Jan 25 update (64.0.3282.123)? I think this may be what is causing this report: https://bugs.chromium.org/p/chromium/issues/detail?id=808751

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

commit 5c94357c6a860ccf080944586f6ad85919f5bd5f
Author: Isha Bobra <ibobra@google.com>
Date: Tue Feb 13 17:58:18 2018

Android Accessibility: Avoiding Infinite loop of FrameLayouts in a11y tree

Initially https://chromium-review.googlesource.com/c/chromium/src/+/729145
ContentViewCore.java#b1735 shows that if the mWebContentsAccessibility was null or
not enabled, we just create it and enable it. The return value was null for these 2 cases.

This CL tries to get that behavior back and avoid loops.

Bug:  805014 
Change-Id: I967503ec2601311c7bdd92b30bf5567308d4ce80
Reviewed-on: https://chromium-review.googlesource.com/891941
Commit-Queue: Isha Bobra <ibobra@google.com>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Jinsuk Kim <jinsukkim@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536404}
[modify] https://crrev.com/5c94357c6a860ccf080944586f6ad85919f5bd5f/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsGarbageCollectionTest.java
[modify] https://crrev.com/5c94357c6a860ccf080944586f6ad85919f5bd5f/content/public/android/java/src/org/chromium/content/browser/accessibility/WebContentsAccessibilityImpl.java
[modify] https://crrev.com/5c94357c6a860ccf080944586f6ad85919f5bd5f/content/public/android/java/src/org/chromium/content_public/browser/WebContentsAccessibility.java
[modify] https://crrev.com/5c94357c6a860ccf080944586f6ad85919f5bd5f/content/public/android/javatests/src/org/chromium/content/browser/accessibility/WebContentsAccessibilityTest.java

[Auto-generated comment by a script] We noticed that this issue is targeted for M-65; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-65 label, otherwise remove Merge-TBD label. Thanks.

Please verify the fix in canary and request merge approval for M65

Verified with following steps.

Reproduce steps:
1. Open Chrome
2. Go to search.yahoo.com
3. Search for "Best smartphones"
4. Activate SelectToSpeak and draw selection on the page.

Observed and expected result:
SelectToSpeak does not crash.

This bug requires manual review: M65 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit a3f5f6331e435918721203cdc6e07e3c541d6aae
Author: Isha Bobra <ibobra@google.com>
Date: Wed Feb 21 04:01:33 2018

Merge to M65: Android Accessibility: Avoiding Infinite loop of FrameLayouts in a11y tree

Initially https://chromium-review.googlesource.com/c/chromium/src/+/729145
ContentViewCore.java#b1735 shows that if the mWebContentsAccessibility was null or
not enabled, we just create it and enable it. The return value was null for these 2 cases.

This CL tries to get that behavior back and avoid loops.

Bug:  805014 
Change-Id: I4c880cf3f6fc482559b3cc81a3afbe22ae2fd199
Reviewed-on: https://chromium-review.googlesource.com/927861
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#527}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/a3f5f6331e435918721203cdc6e07e3c541d6aae/android_webview/javatests/src/org/chromium/android_webview/test/AwContentsGarbageCollectionTest.java
[modify] https://crrev.com/a3f5f6331e435918721203cdc6e07e3c541d6aae/content/public/android/java/src/org/chromium/content/browser/ContentViewCoreImpl.java
[modify] https://crrev.com/a3f5f6331e435918721203cdc6e07e3c541d6aae/content/public/android/java/src/org/chromium/content/browser/accessibility/WebContentsAccessibility.java
[modify] https://crrev.com/a3f5f6331e435918721203cdc6e07e3c541d6aae/content/public/android/javatests/src/org/chromium/content/browser/accessibility/WebContentsAccessibilityTest.java