UI 자동화와 관련된 Chrome 접근 가능한 트리 캐시 문제

Chrome은 사용자가 브라우저에서 아래로 스크롤 할 때 내게 필요한 옵션 요소 ( AutomationElement )를 새로 고치지 않습니다 .

그것을 재현하려면 :

1. 을 사용 "chrome --force-render-accessibility"하거나에서 전역 액세스 가능성을 설정하여 렌더러 액세스 가능성을 활성화하십시오 "chrome://accessibility".
2. http://en.wikipedia.org/wiki/Google로 이동
3. UI 자동화 모드 (Windows 키트)에서 inspect.exe 를 열고 "관련 기사에 대한 링크"요소를 찾으십시오.
4. Chrome으로 돌아와 하단의 '관련 기사 링크'가 표시 될 때까지 아래로 스크롤
5. "관련 기사 링크"요소가 화면에 표시되지 않음

Chrome에서 강제로 새로 고칠 수있는 몇 가지 수동 솔루션을 찾았습니다.

1. 확대 / 축소를 90 %로 설정 한 다음 다시 100 %로 설정하십시오 (매우 추악한 방법).
2. 내게 필요한 옵션을 껐다 켜십시오 chrome://accessibility/

내가 찾고있는 것은 이러한 작업 중 하나를 프로그래밍 방식으로 수행하거나 Chrome에서 캐시 트리를 새로 고칠 수있는 작업입니다.

내가 시도한 것 :

• 창 크기 조정 PInvoke/MoveWindow
• 창 다시 그리기 PInvoke/Redrawwindow
• 크롬 확장 프로그램을 구축하고 필요에 따라 100 % 확대 / 축소 :( chrome.tabs.setZoom(null, 0);작동하지만 깜박임 및 속도 저하)

이들 중 어느 것도 제대로 작동하지 않습니다.

편집 : Windows 7에서 Chrome 40.XX, 41.XX, 42.XX, 43.XX, 44.XX, 45.XX, 46.XX, 47.XX.Dev, 48.XX.Dev로 테스트되었습니다.

간단한 페이지에서의 스크롤은 렌더러에서 계산할 필요가 없도록 최적화되어 있습니다. 컴포 지터와 GPU 만 스크롤해야하므로 렌더러에서만 업데이트되는 렌더 트리는 여전히 동일합니다.

렌더러가 DOM을 탐색하고 스크롤하는 동안 접근성 트리를 업데이트하도록 요구하는 것은 몇 년 동안 터치 장치에 대한 부드러운 스크롤링 노력과 반대로 작동하므로 버그 수정에 대한 견인력을 얻지 못할 것이라고 생각합니다.

확장에 대한 당신의 생각은 (추악한) 최선의 타협이라고 생각합니다. 그러나 오히려 확대 / 축소를 변경하고 페이지 (또는 DOM)를 약간만 변경하는 것이 더 나은 솔루션 일 수 있습니다. 예를 들어 z 순서가 낮은 보이지 않는 (또는 거의) 요소를 추가하십시오. 또한 돌연변이를 평가하여 초당 1 회 또는 그보다 덜 자주 발생하도록해야합니다.

Chrome의 다중 프로세스 아키텍처는 다른 브라우저와 다릅니다. 보안을 위해 기본 브라우저 UI는 하나의 프로세스에 있으며 웹 페이지는 별도의 렌더러 프로세스 (일반적으로 탭당 하나)에서 실행됩니다. 렌더러 프로세스는 웹 페이지의 DOM 및 모든 접근성 정보를 나타내는 유일한 프로세스이지만 렌더러 프로세스는 특히 운영 체제 (이벤트 또는 메시지 보내기 또는 받기)와 상호 작용할 수 없습니다. 특히 렌더러 프로세스는 내게 필요한 옵션 이벤트를 보내거나받을 수 없습니다.