Issue metadata
Sign in to add a comment
|
ChromeVox focus gets reset back to the top of the page while navigating |
||||||||||||||||||||||
Issue descriptionPrecondition: enable spoken feedback on Chrome OS (Ctrl+Alt+Z), on Chrome 56. This can be reproduced on any page, but it's not always consistent. Two reports that can be reproduced, but not totally reliably: 1. Do a Google search, on the search results page press Search+E for the edit box, then press Shift+Right to navigate through the page. Sometimes you cycle back up to the top rather than making it through the page. 2. Open hbogo.com/activate, press Tab once, then press Search+Right to navigate through the page. Again, sometimes you cycle back up to the top rather than making it through the page. 100% reliable repro of the same underlying issue but requires ability to see and use the mouse: 1. Open a browser window and make sure it is not maximized. You should be able to drag the title bar. 2. Open Wikipedia, http://en.wikipedia.org 3. Press Search+H to jump to the "From Today's Featured Article" heading 4. Use the mouse to click and move the window a few pixels ChromeVox focus jumps back to the whole document (the orange highlight), and subsequent navigation starts from the top, instead of from the heading. It should be unaffected.
,
Nov 7 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/5e5850d17ba180e02b1e7bd6d5fb1d3bdb01972e commit 5e5850d17ba180e02b1e7bd6d5fb1d3bdb01972e Author: dmazzoni <dmazzoni@chromium.org> Date: Mon Nov 07 20:45:57 2016 automation_custom_bindings needs to handle blur events too. In the automation API used by ChromeVox, focus events are handled specially, because windows tend to fire focus events due to local focus changes even when they don't have focus globally - so when we get a focus event we use that as a signal to compute which node really has focus and fire the focus event on the proper node if needed. However, Chrome also fires "blur" events, and when focus is lost that's the only event that will fire, and it needs to be handled the same way. Leaving out "blur" led to a bug where calling setSequentialFocusNavigationStartingPoint on a node would cause focus to be lost (correctly), but ChromeVox wouldn't get the notification that focus was lost right away with eventFrom=action. So when focus was checked later, ChromeVox would discover that focus was suddenly on the root of the document and mistakenly treat that as a real focus event. When blur is handled the same way as focus in automation_custom_bindings, ChromeVox gets the blur event immediately in response to calling setSequentialFocusNavigationStartingPoint, and because eventFrom=action is set, it ignores it (correctly), and navigation of the page is unaffected. BUG= 662441 TESTED=Manually tested all three repros from bug 662441 Review-Url: https://codereview.chromium.org/2479563004 Cr-Commit-Position: refs/heads/master@{#430368} [modify] https://crrev.com/5e5850d17ba180e02b1e7bd6d5fb1d3bdb01972e/chrome/renderer/resources/extensions/automation_custom_bindings.js |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by dtseng@chromium.org
, Nov 7 2016