The default bug view has changed. See this FAQ.

Correct logic to determine if nsDocAccessible is focusable

VERIFIED FIXED in mozilla10

Status

()

Core
Disability Access APIs
VERIFIED FIXED
10 years ago
6 years ago

People

(Reporter: Aaron Leventhal, Assigned: surkov)

Tracking

(Blocks: 1 bug, {access})

Trunk
mozilla10
access
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
Right now in nsDocAccessible::GetState() we have a hack to determine if a document is focusable. We consider all HTML docs focusable and all XUL docs unfocusable.

We need a better way. A XUL <iframe> could contain a scrollable XUL document, which should be focusable (we better make sure it is!) I was not able to find a way to use frame->IsFocusable() to find out if a doc is focusable.
(Reporter)

Comment 1

10 years ago
Also, this is a follow-up from bug 375747. The new focusable check for nsDocAccessible comes from that fix.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Editable frames should be focusable too, presumably.
(Assignee)

Updated

6 years ago
Blocks: 640520
(Assignee)

Updated

6 years ago
Depends on: 673958
Flags: in-testsuite?
(Assignee)

Comment 4

6 years ago
fixed by bug 673958
Assignee: nobody → surkov.alexander
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla10

Comment 5

6 years ago
Verified fixed and by inspecting the mochitests from bug 673958 in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.