Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

VERIFIED FIXED in Firefox 7

Status

()

Firefox
Tabbed Browser
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: Jamie, Assigned: dao)

Tracking

(Blocks: 2 bugs, {access, verified-aurora})

Trunk
Firefox 7
access, verified-aurora
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

4.65 KB, patch
Neil Deakin (not available until Aug 9)
: review+
Details | Diff | Splinter Review
(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Keywords: access

Comment 1

7 years ago
I have seen this bug as well.
Status: UNCONFIRMED → NEW
Component: Disability Access → Disability Access APIs
Ever confirmed: true
Product: Firefox → Core
QA Contact: disability.access → accessibility-apis
Version: unspecified → Trunk
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?

Comment 4

7 years ago
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.

Comment 6

7 years ago
Confirmed regression range as Alice points out. Thanks!
Okay we need to get Neil a debugging focus log (enable the #defines in nsFocusManager).

Comment 8

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

Comment 9

7 years ago
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!

Updated

7 years ago
Blocks: 375743
(Reporter)

Comment 10

6 years ago
(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.
(Reporter)

Updated

6 years ago
Blocks: 659863

Comment 11

6 years ago
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.

Comment 13

6 years ago
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?
(Assignee)

Updated

6 years ago
Component: Disability Access APIs → Tabbed Browser
Product: Core → Firefox
QA Contact: accessibility-apis → tabbed.browser
(Assignee)

Comment 14

6 years ago
Created attachment 543391 [details] [diff] [review]
patch
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #543391 - Flags: review?(enndeakin)
(Assignee)

Updated

6 years ago
OS: Windows 7 → All
Hardware: x86 → All
Attachment #543391 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 15

6 years ago
http://hg.mozilla.org/mozilla-central/rev/128d2f9f7ac3
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 7

Comment 16

6 years ago
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
Keywords: verified-aurora
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!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.