Closed Bug 424757 Opened 13 years ago Closed 12 years ago

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

Categories

(Core :: Disability Access APIs, defect, P2)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: MarcoZ, Assigned: ginnchen+exoracle)

References

Details

(Keywords: access, regression)

Attachments

(1 file, 1 obsolete file)

1.70 KB, patch
aaronlev
: review+
beltzner
: approval1.9+
Details | Diff | Splinter Review
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?
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
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.
Attached patch patch (obsolete) — Splinter Review
Assignee: aaronleventhal → ginn.chen
Status: NEW → ASSIGNED
Attachment #312860 - Flags: review?(aaronleventhal)
Attached patch patchSplinter Review
remove the TAB
Attachment #312860 - Attachment is obsolete: true
Attachment #312862 - Flags: review?(aaronleventhal)
Attachment #312860 - Flags: review?(aaronleventhal)
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?
Macro, I don't know what should be tested.
I think the patch is low risk.
Attachment #312862 - Flags: review?(aaronleventhal)
Attachment #312862 - Flags: review+
Attachment #312862 - Flags: approval1.9?
this bug is blocking1.9+, we don't need approval1.9, do we?
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
Closed: 12 years ago
Resolution: --- → FIXED
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.