338141 - Focus events fired for unfocused controls

Status: RESOLVED DUPLICATE of bug 338234

(Core :: Disability Access APIs, defect)

Description

[parente]

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.

Comment 1

[parente]

Attachment: Focus event test (requires pyLinAcc.zip in same folder)

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

Comment 2

[parente]

Attachment: pyLinAcc interface to at-spi (required for test case)

Place in same directory as test case. Do not unzip.

Comment 3

[Aaron Leventhal]

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

Huge regression.

Comment 4

[Ginn Chen]

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

Comment 5

[parente]

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

[Aaron Leventhal]

(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

[Ginn Chen]

*** This bug has been marked as a duplicate of 338234 ***

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381