Focus events fired for unfocused controls

RESOLVED DUPLICATE of bug 338234

Status

()

Core
Disability Access APIs
--
major
RESOLVED DUPLICATE of bug 338234
12 years ago
12 years ago

People

(Reporter: parente, Assigned: Mike Gao)

Tracking

({access, regression, sec508})

Trunk
x86
All
access, regression, sec508
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
Two examples:

On select Customize Character Encoding menu item

window:deactivate(0, 0, Bon Echo)[Bon Echo, frame]
window:activate(0, 0, Customize Character Encoding)[Customize
Character Encoding, frame]
focus(0, 0, None)[Available Character Encodings:, list]
focus(0, 0, None)[Arabic (IBM-864), list item]
focus(0, 0, None)[Available Character Encodings:, list]
focus(0, 0, None)[None, panel]

The character encoding list, not the panel, actually has focus at this point. (And the first list item is the active descendant.)

Opening preferences dialog

window:deactivate(0, 0, Bon Echo)[Bon Echo, frame]
window:activate(0, 0, Bon Echo Preferences)[Bon Echo Preferences,
dialog]
focus(0, 0, None)[None, list]
focus(0, 0, None)[None, panel]

Again, the list has focus, not this unidentified panel. Press left arrow to move from content to privacy list item:

focus(0, 0, None)[Privacy, list item]
focus(0, 0, None)[Content, list item]

The focus on the privacy list item fires correctly, but then we get a focus event on the content list item which just lost focus.

This behavior confuses screen readers. For instance, gnopernicus should be announcing focus on the character encoding list, on the preferences section list, and on the privacy list item. Instead, it incorrectly announces the focus on a blank panel, a blank panel, and on the content item. The same behavior is evident when using LSR.

Updated

12 years ago
Assignee: aaronleventhal → gaomingcn

Updated

12 years ago
Keywords: access, sec508
(Reporter)

Comment 1

12 years ago
Created attachment 222392 [details]
Focus event test (requires pyLinAcc.zip in same folder)

Download pyLinAcc.zip file also to run this test. No need to unpack the zip.
(Reporter)

Comment 2

12 years ago
Created attachment 222393 [details]
pyLinAcc interface to at-spi (required for test case)

Place in same directory as test case. Do not unzip.
(Reporter)

Updated

12 years ago
Attachment #222392 - Attachment description: Focus event test (required pyLinAcc.zip in same folder) → Focus event test (requires pyLinAcc.zip in same folder)

Comment 3

12 years ago
Same behavior is happening on Windows. To test, run Inspect and click the yellow rectangle in the toolbar to watch focus.

Huge regression.
Severity: normal → major
OS: Linux → All

Updated

12 years ago
Keywords: regression

Comment 4

12 years ago
same behavior on Windows?

I'm not sure, but the last part is a dupe of Bug 338234
"The focus on the privacy list item fires correctly, but then we get a focus
event on the content list item which just lost focus."

See, https://bugzilla.mozilla.org/show_bug.cgi?id=338234#c3
(Reporter)

Comment 5

12 years ago
Yes. Same finding. Timestamps show both bugs were opened on the same day, just hours apart.

Aaron, what is the preferred naming convention for these bugs in order to prevent dupes? One convention is to state what is wrong from the point of view of Firefox (e.g. firing focus events for unfocused controls). Another is to say what a particular AT observes (e.g. orca can't report preference names).

Comment 6

12 years ago
(In reply to comment #5)
Preference is to name them based on what Firefox is doing wrong if you can get that information.

Comment 7

12 years ago

*** This bug has been marked as a duplicate of 338234 ***
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.