User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100503 Minefield/3.7a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100503 Minefield/3.7a5pre When focused on the tab bar and using the left and right arrow keys to switch between tabs, a focus event is incorrectly fired on the document before the focus event for the newly active tab. Reproducible: Always Steps to Reproduce: 1. Open two tabs. ensuring that the document itself is focused in each; i.e. not a focusable descendant such as a link. 2. Move focus to the tab bar. 3. Select the first tab. 4. Press rightArrow. Actual: A focus event is fired on the second document before the focus event for the second tab is fired. Expected: Only the focus event on the tab should be fired. 5. Press leftArrow. Actual: A focus event is fired on the first document before the focus event for the first tab is fired. Expected: Only the focus event on the tab should be fired. This causes annoying reading of document content in NVDA when the user is only interested in hearing the information about the currently focused tab.
I have seen this bug as well.
Regression window wanted :)
I suspect when a new page is shown there is code to focus the last focused thing in the document. Neil is there? Should we suppress when focus is in chrome?
If I do not misread STR, regression window is as follows: Works: http://hg.mozilla.org/mozilla-central/rev/90d3e6d2cbb9 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090610 Namoroka/3.6a1pre ID:20090610042525 Fails: http://hg.mozilla.org/mozilla-central/rev/4430cae50dad Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090611 Namoroka/3.6a1pre ID:20090611044033 pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=90d3e6d2cbb9&tochange=4430cae50dad Candidate: Bug 178324 - refactor focus handling
Alice, thanks! I think we need to hear from Neil on this one.
Confirmed regression range as Alice points out. Thanks!
Okay we need to get Neil a debugging focus log (enable the #defines in nsFocusManager).
Marco, could you please check if it's still valid?
Oh yes, now focus gets thrown into the virtual buffer even though I believe visually it is still at the top of the screen in the tab bar. So in a way, this recently worstened even!
(In reply to comment #9) > Oh yes, now focus gets thrown into the virtual buffer even though I believe > visually it is still at the top of the screen in the tab bar. So in a way, this > recently worstened even! Confirmed. Previously, focus was fired on the tab after being fired on the document, so it was a minor verbosity annoyance for screen reader users. Now, focus is incorrect/broken.
It appears this is implementation details of UI since DOM focus is fired on tab document and then on tab. Due to some reason a11y events are fired in reverse order what's a regression (what's Jamie noticed in comment #10). I would like to hear Enn whether document focus is necessary and can be fixed on content/toolkit part.
(In reply to comment #3) > I suspect when a new page is shown there is code to focus the last focused > thing in the document. Neil is there? Should we suppress when focus is in > chrome? Yes, the content is focused when switching tabs. See http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#985 Then the tabbox code focuses the tab again. The behaviour of focus on tab switching has been changed at various times, to either maintain focus when a chrome element is focused to not doing so. There doesn't seem to be a general solution that would handle all ui elements in all situations. This particular case seems easily fixable though. Dão might have more comments about it.
Focus events for content and chrome documents are processed separately on a11y side, I think the order can't be guaranteed. And as you can see events for tab are fired earlier due to some reason. I don't have clever idea how to fix that on a11y side taking into account ongoing multi-process support. Dão, can you comment please?
Created attachment 543391 [details] [diff] [review] patch
Can you please update the STR in order to verify this bug. Thx
The STR are still valid. Downloading a current nightly to verify now.
Verified fixed in Aurora build Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110707 Firefox/7.0a2
Verified in Mozilla/5.0 (Windows NT 6.1; rv:8.0a1) Gecko/20110707 Firefox/8.0a1. Focus now stays on the tab bar when left and right arrowing, and NVDA's virtual mode is not enabled when it shouldn't, any more. Thanks!