UI Automation的Google Chrome浏览器可访问树缓存问题

当用户在浏览器中向下滚动时，Google Chrome不会刷新可访问性元素（AutomationElement）。

要重现它：

1. 使用"chrome --force-render-accessibility"或通过在上设置全局可访问性启用渲染器可访问 性"chrome://accessibility"。
2. 前往http://en.wikipedia.org/wiki/Google
3. 在UI自动化模式下（从Windows Kits中）打开inspect.exe，查找“到相关文章的链接”元素。
4. 返回Chrome，向下滚动直到底部的“相关文章链接”可见
5. 屏幕上标记了“到相关文章的链接”元素

我找到了一些手动的解决方案，它们可能会迫使Chrome刷新它：

1. 将“缩放”设置为90％，然后将其设置回100％（非常难看）
2. 关闭辅助功能，然后再打开 chrome://accessibility/

我要寻找的是能够以编程方式执行这些操作之一的功能，或者能够使Chrome刷新其缓存树的任何操作。

我试过的

• 调整窗口大小 PInvoke/MoveWindow
• 重绘窗口 PInvoke/Redrawwindow
• 构建chrome扩展程序，并根据需要强制缩放到100％：（可以chrome.tabs.setZoom(null, 0);工作，但要眨眼并放慢窗口速度）

这些都不正常。

编辑：在Windows 7下使用Google Chrome 40.XX，41.XX，42.XX，43.XX，44.XX，45.XX，46.XX，47.XX.Dev，48.XX.Dev进行了测试。

优化了在简单页面中的滚动，以不需要渲染器进行计算。仅需要合成器和GPU即可滚动，因此仅从渲染器更新的渲染树仍然相同。

要求渲染器在滚动过程中遍历DOM并更新“可访问性”树，这与经过数年努力使平滑滚动（特别是对于触摸设备）的努力相反，因此我认为您不会在bug修复上大受好评。

我认为您对扩展的想法是最好的（尽管很丑陋）折衷。但是，改变缩放比例，对页面（或DOM）进行少量修改可能是更好的解决方案。例如，尝试添加一个Z轴较低的不可见（或几乎如此）的元素。您还需要对突变进行速率控制，以使其仅每秒发生1次甚至更少。

Chrome的多进程体系结构与任何其他浏览器均不同。为了安全起见，主浏览器UI处于一个进程中，网页在单独的渲染器进程中运行（通常每个选项卡一个）。呈现器进程是唯一具有网页DOM以及所有可访问性信息表示形式的进程，但是特别不允许呈现器进程与操作系统（发送或接收事件或消息）进行交互（尤其是呈现器）进程无法发送或接收可访问性事件。