Intermittent misplaced keyboard focus with screen-reader active

RESOLVED WORKSFORME

Status

()

Core
Disability Access APIs
RESOLVED WORKSFORME
7 years ago
6 years ago

People

(Reporter: zwol, Unassigned)

Tracking

(Blocks: 2 bugs, {access})

1.9.2 Branch
x86
Windows 7
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
Created attachment 501857 [details]
test case

The attached HTML file (note: may not work correctly if viewed in bugzilla due to link to YUI from Yahoo CDN) shows an intermittent keyboard focus problem in the presence of an active screenreader.  The HTML contains two buttons, but JS hides one of them on load; when one button is activated (with mouse or keyboard), JS hides that one, shows the other one, and assigns it the keyboard focus.  So if you click on a button and then hold down Enter, the visible button will oscillate between the two.  However, if a screenreader is active, after several such cycles, keyboard focus winds up on the word "text".
  Removing the <ul> and <li> elements surrounding the buttons makes the problem go away, as does increasing the delay in the setTimeout calls to 250ms delay.


The person who originally found the bug was using NVDA under Windows 7.  I was unable to reproduce it using Orca under GNOME, but I could very easily believe that this was Windows-specific.  Both of us used Firefox 3.6.
Component: Event Handling → Disability Access APIs
QA Contact: events → accessibility-apis
(Reporter)

Comment 1

7 years ago
Created attachment 501991 [details]
simplified test case

I still can't reproduce the problem with Orca, but here is a simplified test case that has no YUI dependency and may more reliably show the problem with NVDA.  I'm informed that the right way to trigger it is to tap the Enter key repeatedly, not hold it down, and that it usually takes between 6 and 20 cycles.

I would have filed this under Disability Access APIs in the first place, but the component description for that specifically says not to file focus bugs there.
Thanks Zack, has anyone confirmed this bug in FF4 beta?
Version: Trunk → 1.9.2 Branch
(Reporter)

Comment 3

7 years ago
No, and I can't conveniently do that.  I'm a Linux/Mac guy, and the person who saw the problem on Windows has flat refused to use our betas until we have a side-by-side installation experience on a par with Opera's (I think I filed a bug for that a few years ago).
Oh yes, this is definitely confirmed! In a current FX4 nightly, this problem is even worse than in FX 3.6.x. In the current nightly, it takes exactly 1 cycle to show the problem. Tap the Enter key twice, and when it is supposed to cycle back to "Archive", it already fails. With FX 3.6.x, I need about 20 tries.
Would be good to test this against the latest try build on bug 498015. That said, I do recall reviewing some changes to our focus code in Nov/Dec time frame.
Possible suspect: bug 615189

Comment 7

7 years ago
(In reply to comment #5)
> Would be good to test this against the latest try build on bug 498015.

The bug is still present.

Updated

7 years ago
Blocks: 375743, 632301

Comment 8

6 years ago
That's something Jamie should look into. I cannot reproduce the problem when a11y is active but I definitely can with NVDA running. It could be NVDA bug.
No longer able to reproduce. Probably fixed by focus rework in bug 673958. Please reopen if you still see an issue with 10.0a1.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.