623758 - Intermittent misplaced keyboard focus with screen-reader active

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[Zack Weinberg (:zwol)]

Attachment: 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.

Comment 1

[Zack Weinberg (:zwol)]

Attachment: 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.

Comment 2

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

Thanks Zack, has anyone confirmed this bug in FF4 beta?

Comment 3

[Zack Weinberg (:zwol)]

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

Comment 4

[Marco Zehe (:MarcoZ)]

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.

Comment 5

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

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.

Comment 6

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

Possible suspect: bug 615189

Comment 7

[alexander :surkov (:asurkov)]

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

The bug is still present.

Comment 8

[alexander :surkov (:asurkov)]

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.

Comment 9

[Marco Zehe (:MarcoZ)]

No longer able to reproduce. Probably fixed by focus rework in bug 673958. Please reopen if you still see an issue with 10.0a1.