No focus event when returning focus to the Location bar from a search result list item

VERIFIED FIXED

Status

()

Core
Disability Access APIs
P2
major
VERIFIED FIXED
10 years ago
10 years ago

People

(Reporter: MarcoZ, Assigned: Ginn Chen)

Tracking

({access, regression})

Trunk
x86
Windows XP
access, regression
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

1.70 KB, patch
Aaron Leventhal
: review+
beltzner
: approval1.9+
Details | Diff | Splinter Review
(Reporter)

Description

10 years ago
When returning focus to the location bar, no focus event is fired to indicate this.

STR:
1. Open Minefield.
2. Type in something into the Location bar that you know you have visited or bookmarked.
3. Press DownArrow to make a selection in the list of search results.
4. Press RightArrow to return to the Location bar edit combo.

Expected: Screen readers such as NVDA or JAWS should announce the focus change.
Actual: No focus change is present. AccEvent32 shows that no focus event is fired for the edit combo.
Flags: blocking1.9?
(Reporter)

Comment 1

10 years ago
Turns out this was broken with the initial checkin of bug 407359 already. I remember testing one of the prior patches/try server builds for that bug, where this definitely worked. But somewhere along the lines of the patch development this was broken and not caught.
If this does indeed break the screen readers, and we regressed, we should fix this.  Can we get a confirmation that bug 407359 is really the culprit?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
(Reporter)

Comment 3

10 years ago
Like I said above: It was meant to work in that original patch, and this functionality somehow got lost between the last try-server build I tried and the final patch that was checked in.
(Assignee)

Comment 4

10 years ago
Created attachment 312860 [details] [diff] [review]
patch
Assignee: aaronleventhal → ginn.chen
Status: NEW → ASSIGNED
Attachment #312860 - Flags: review?(aaronleventhal)
(Assignee)

Comment 5

10 years ago
Created attachment 312862 [details] [diff] [review]
patch

remove the TAB
Attachment #312860 - Attachment is obsolete: true
Attachment #312862 - Flags: review?(aaronleventhal)
Attachment #312860 - Flags: review?(aaronleventhal)
(Reporter)

Comment 6

10 years ago
I tested this patch, and it does indeed fix the problem!

Ginn, any other scenarios I should try which might be affected? For example any special comboboxes or the like?
(Assignee)

Comment 7

10 years ago
Macro, I don't know what should be tested.
I think the patch is low risk.

Updated

10 years ago
Attachment #312862 - Flags: review?(aaronleventhal)
Attachment #312862 - Flags: review+
Attachment #312862 - Flags: approval1.9?

Comment 8

10 years ago
this bug is blocking1.9+, we don't need approval1.9, do we?
(Reporter)

Comment 9

10 years ago
Checking in accessible/src/base/nsRootAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsRootAccessible.cpp,v  <--  nsRootAccessible.cpp
new revision: 1.266; previous revision: 1.265
done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 10

10 years ago
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040204 Minefield/3.0pre
Status: RESOLVED → VERIFIED
Comment on attachment 312862 [details] [diff] [review]
patch

a1.9=beltzner
Attachment #312862 - Flags: approval1.9? → approval1.9+
You need to log in before you can comment on or make changes to this bug.