Fix issue with ax trees not destroyed for reused rfh
This CL fixes a problem whereby ax trees created for iframes that have navigated elsewhere were not being destroyed after the render frame is destroyed. Prior to this CL, if a render frame host was reused after navigation, its ax tree id was being overwritten with a new tree id. When the render frame eventually gets destroyed, only the last ax tree id would get a DispatchTreeDestroyed event. This left the earlier tree parent-less inside the ChromeVox background script since it never received a destroyed event. If the reader was focused on an element from the previous tree, the user could still swipe navigate to those elements even though the page had navigated elsewhere. Solution is to listen for navigation changes in the automation web contents observer and destroy any old tree ids that are set on the render frame host. Added a chrome.automation test case to reproduce the issue. An iframe is first pointed to a resource with a button "First Button". A top level button will swap the 'src' attribute for another resource once clicked. The test makes sure that the role attribute of the first button becomes undefined, indicating it's tree was properly destroyed. Prior to this CL, it's role attribute was not undefined because the tree destroyed event was never sent for the old tree. Test: Added chrome.automation test case, would consistently fail prior to this CL Bug: 173650630 Change-Id: Ie9228b19c7e84db7c3c2a70566584605794a6b83 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2572729Reviewed-by:Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by:
David Tseng <dtseng@chromium.org> Commit-Queue: Randy Rossi <rmrossi@chromium.org> Cr-Commit-Position: refs/heads/master@{#844084}
Showing
Please register or sign in to comment