fixes focus recovery when closing a window
Scenario: - chrome://settings - under advanced -> accessibility, click add accessibility features - Ctrl+w - Search+Right result: ChromeVox accessibility focus moves to the root of the settings page Explanation The sequence of events immediately after Ctrl+w are as follows: "focus webView" ... "ariaAttributeChanged window" "blur webView" "focus unknown" ... "ariaAttributeChanged window" "blur unknown" "focus link" ... "<accessibility event type> <target node's role>" The typical event stream from an interaction where a page gets initial focus always involves the "rootWebArea" getting focused (this is typically a child of the webView node). Fix The fix is to always refresh DesktopAutomationHandler's |lastRootUrl| state for every focus event not just ones on a rootWebArea. This state is used to prevent ChromeVox from trying to recover focus when a user has already started navigating into a page before the page has completely loaded. In the case where someone closes a window, the focus never actually lands on the rootWebArea first but instead on the webView only. The existing check is: - ChromeVox accessibility focus's root == the new focus's root and - the last root url == the new focus's root url Test: The cases that continue to work: - alt+tab (roots are different, root urls are different, focus recovery triggers) - reload (ctrl+r) - ctrl+tab - alt+left (root can actually be the same, but root urls different which triggers recovery) New: - Ctrl+w Verify all these cases recover to the previous place and Search+left/right work as expected after. Bug: 1003992 Change-Id: If09ab14a4aafb3e0a849266eebf69315b277d005 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1804048 Commit-Queue: David Tseng <dtseng@chromium.org> Reviewed-by:Dominic Mazzoni <dmazzoni@chromium.org> Cr-Commit-Position: refs/heads/master@{#696605}
Showing
Please register or sign in to comment