用户界面自动化导致的 Google Chrome 可访问树缓存问题

当用户在浏览器中向下滚动时，GoogleChrome 不会刷新可访问性元素(AutomationElement 自动化元素)。

为了复制它:

  1. 使用: "chrome --force-render-accessibility"或通过设置 "chrome://accessibility"的全局可访问性来启用渲染器可访问性。
  2. 转到 http://en.wikipedia.org/wiki/Google
  3. 在 UI 自动化模式下打开 检查，执行(来自 Windows 工具包) ，查找“链接到相关文章”元素。
  4. 回到 Chrome，向下滚动，直到底部的“相关文章链接”可见
  5. “相关文章的链接”元素在屏幕上被标记出来

我发现了一些手动解决方案，可以迫使 Chrome 更新它:

  1. 将 Zoom 设置为90% ，然后将其设置为100% (非常非常难看的方式)
  2. 关闭可访问性，然后在 chrome://accessibility/中打开

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

我试过的方法:

  • 使用 PInvoke/MoveWindow调整窗口大小
  • 用 PInvoke/Redrawwindow重绘窗口
  • 建立一个铬扩展，并强制缩放到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 进行测试。

5415 次浏览
小开

Chrome 的多进程架构与其他浏览器不同。为了安全起见，主浏览器 UI 在一个进程中，网页在单独的渲染器进程中运行(通常每个选项卡一个)。渲染器进程是唯一一个表示网页的 DOM，因此所有的可访问性信息的进程，但是渲染器进程不允许与操作系统交互(发送或接收事件或消息)——特别是，渲染器进程不能发送或接收可访问性事件。

小开

对简单页面中的滚动进行了优化，使其不需要从呈现程序进行计算。只有排字器和 GPU 需要滚动，因此渲染树只是从渲染器更新仍然是相同的。

要求渲染器在滚动过程中遍历 DOM 并更新可访问性树，与几年来努力实现平滑滚动相反，特别是对于触摸设备，所以我不认为你会在 bug 修复上获得牵引力。

我认为你关于延期的想法是最好(尽管丑陋)的妥协。但是更改缩放，对页面(或 DOM)进行一个小的变异可能是一个更好的解决方案。例如，尝试添加一个 z 阶较低的不可见(或几乎不可见)元素。你还需要控制突变的频率，这样它每秒只会发生1次，甚至更少。


提交答案