Setting the caret offset and grabbing focus sometimes fail to update focused widget
Categories
(Core :: Disability Access APIs, defect, P3)
Tracking
()
People
(Reporter: jdiggs, Unassigned)
References
(Blocks 2 open bugs)
Details
Steps to reproduce:
-
Tab/Shift+Tab until the "Hacker News" link at the top of the page is focused
-
Launch Accerciser and in its tree of accessible objects, select the table row with the name "Rechargeable vs. Alkaline Batteries"
-
In Accerciser's iPython console, type the following:
acc.queryText().setCaretOffset(0)
acc.queryComponent().grabFocus()
Expected results: One of the above would cause focus to be removed from the Hacker News link
Actual results: Neither of the above cause focus to be removed from the Hacker News link
Impact: When an Orca user uses Orca caret navigation to read page content, it sets the caret offset. One of the reasons it does this is to update focus so that when the user presses Tab, Firefox moves focus to the next focusable object after the thing Orca just presented. Due to this bug, when the user presses Tab after moving to "Rechargeable vs. Alkaline Batteries", focus goes to the "new" link.
Aside: I do realize that the accessible text indicates there are 0 characters in the table row, and also that the table row is not technically focusable. But I need some way to update focus so that Tab does what the users expect it to. Thanks in advance.
Reporter | ||
Comment 1•5 years ago
•
|
||
BTW, if you use Accericser to examine the name of the table row immediately after the one I state in the opening report, you'll discover that the accessible name appears to be constructed of the bulk of the contents of that page. Its length is a whopping 32,874 characters (presently). While I could be wrong, that cannot be good for performance.....
Comment 2•5 years ago
|
||
Do things behave as you need them to if you call setCaretOffset(1) on the table which is the parent of that row; i.e. you're moving the caret to the row in the table (as opposed to a non-existent cell)? This is obviously kinda ugly, but on the other hand, allowing for setting of the caret in empty text also doesn't make much sense. I guess we could try to special case setCaretOffset for empty text to do exactly what I'm suggesting; i.e. fall back to the embed point.
Reporter | ||
Comment 3•5 years ago
|
||
Just tried it. It moves focus just before the "Hacker News" link. But I see what you're saying. However, if one of us has to sanity check this, I'd be grateful if you could do that work on your side. Orca's already having to sanity check a ton of things and it's not good for performance.
Comment 4•5 years ago
|
||
(In reply to Joanmarie Diggs from comment #3)
Just tried it. It moves focus just before the "Hacker News" link.
Just to be extra clear, is that what you want when calling setCaretOffset(0) on the row?
But I see what you're saying. However, if one of us has to sanity check this, I'd be grateful if you could do that work on your side. Orca's already having to sanity check a ton of things and it's not good for performance.
Fair.
Updated•2 years ago
|
Description
•