Google Chrome accessible tree cache issue with UI Automation

Question

Google Chrome does not refresh accessibility elements (AutomationElement) when a user scrolls down in the browser.

To reproduce it:

1. Enable renderer accessibility with : "chrome --force-render-accessibility" or by setting on Global Accessibility at "chrome://accessibility".
2. Go to http://en.wikipedia.org/wiki/Google
3. Open inspect.exe in UI Automation Mode (from Windows Kits), look for "Links to related articles" element.
4. Come back to Chrome, Scroll down until "Links to related articles" at the bottom is visible
5. "Links to related articles" element is marked off screen

---

I found some manual solutions that can force Chrome to refresh it:

1. Set Zoom to 90% then set it back to 100 % (very very ugly way)
2. Switch accessibility off then switch on in chrome://accessibility/

What I'm looking for is the ability to do one of these operations programatically, or any operation that can make Chrome refresh its cache tree.

---

What I've tried:

• Resize window with PInvoke/MoveWindow
• Redraw Window with PInvoke/Redrawwindow
• Build a chrome extension and force zoom to 100% on demand: chrome.tabs.setZoom(null, 0); (working but blink and slow down the window)

None of these are working properly.

EDIT: Tested with Google Chrome 40.XX, 41.XX, 42.XX, 43.XX, 44.XX, 45.XX, 46.XX, 47.XX.Dev, 48.XX.Dev under Windows 7.

Answer 1

Scrolling in simple pages is optimized to not require computation from the renderer. Only the compositor and the GPU are needed to scroll therefore the render tree which is only updated from the renderer is still the same.

Requiring the renderer to traverse the DOM and update the Accessibility tree during a scroll runs contrary with the several years effort of having smooth scrolling, specially for touch devices so I don't think you are going to get traction on a bug fix.

Your idea of an extension I think is the best (although ugly) compromise. But rather that changing zoom, doing a small mutation of the page (or DOM) might be a better solution. Try for example adding a invisible (or nearly so) element with a low z-order. You will also need to rate control the mutation so it only happens 1 times per second or even less often.

Answer 2

Chrome's multi-process architecture is different from that of any other browser. For security, the main browser UI is in one process, and web pages are run in separate renderer processes (typically one per tab). The Renderer processes are the only ones with a representation of the webpage's DOM and therefore all of the accessibility information, but the renderer processes are specifically not allowed to interact with the operating system (sending or receiving events or messages) - in particular, the renderer processes cannot send or receive accessibility events.