563591 - Focus event incorrectly fired on document when moving between tabs on tab bar

Status: VERIFIED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[James Teh [:Jamie]]

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.

Comment 1

[Marco Zehe (:MarcoZ)]

I have seen this bug as well.

Comment 2

[David Bolter [:davidb] (NeedInfo me for attention)]

Regression window wanted :)

Comment 3

[David Bolter [:davidb] (NeedInfo me for attention)]

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?

Comment 4

[Alice0775 White]

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

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Alice, thanks!

I think we need to hear from Neil on this one.

Comment 6

[Marco Zehe (:MarcoZ)]

Confirmed regression range as Alice points out. Thanks!

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

Okay we need to get Neil a debugging focus log (enable the #defines in nsFocusManager).

Comment 8

[alexander :surkov (:asurkov)]

Marco, could you please check if it's still valid?

Comment 9

[Marco Zehe (:MarcoZ)]

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!

Comment 10

[James Teh [:Jamie]]

(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.

Comment 11

[alexander :surkov (:asurkov)]

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.

Comment 12

[Neil Deakin]

(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.

Comment 13

[alexander :surkov (:asurkov)]

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?

Comment 14

[Dão Gottwald [:dao]]

Attachment: patch

Comment 15

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/128d2f9f7ac3

Comment 16

[Vlad [QA]]

Can you please update the STR in order to verify this bug.
Thx

Comment 17

[Marco Zehe (:MarcoZ)]

The STR are still valid. Downloading a current nightly to verify now.

Comment 18

[Marco Zehe (:MarcoZ)]

Verified fixed in Aurora build Mozilla/5.0 (Windows NT 6.1; rv:7.0a2) Gecko/20110707 Firefox/7.0a2

Comment 19

[Marco Zehe (:MarcoZ)]

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!