getFocusedChild() doesn't really (always) get a child

RESOLVED WORKSFORME

Status

()

Core
Disability Access APIs
RESOLVED WORKSFORME
11 years ago
6 years ago

People

(Reporter: Håkan Waara, Unassigned)

Tracking

(Blocks: 1 bug, {access})

Trunk
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [bk1], URL)

(Reporter)

Description

11 years ago
getFocusedChild() sounds like it would give a child that is focused, and null if none of its children are focused. 

However, it just asks the accessibility service to return whichever accessible that is focused (globally). This can be misleading.

Comment 1

11 years ago
Actually for tree it returns the focused descendant.

We can change it so that the returned accessible is set to null if it's not a decsendant, and change the name to getFocousedDescendant.
Keywords: access
(Reporter)

Comment 2

11 years ago
Aaron, could getFocusedDescendant use the caret accessible to quickly fetch the focused element (and then see if it's a descendant)?
(Reporter)

Comment 3

11 years ago
Actually, I think getFocusedElement() would be enough for my uses. This could live on nsIAccessibleDocument

If that's what getFocusedChild() does anyway, we could just move it to the root accessible, and the implementation would make sense.

Updated

11 years ago
Blocks: 389800
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
I don't think this is a bug anymore.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
I don't think this is a bug anymore.
Whiteboard: [bk1]

Comment 7

6 years ago
(In reply to David Bolter [:davidb] from comment #6)
> I don't think this is a bug anymore.

FocusedChild() returns a child always for generic accessible, document accessible may return everything but it appears it's by design. Agree on the bug closing but we should provide a reason why the bug is not valid anymore.
You need to log in before you can comment on or make changes to this bug.