Open Bug 1568229 Opened 5 years ago Updated 2 years ago

Setting the caret offset and grabbing focus sometimes fail to update focused widget

Categories

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

Unspecified
Linux
defect

Tracking

()

People

(Reporter: jdiggs, Unassigned)

References

(Blocks 2 open bugs)

Details

Steps to reproduce:

  1. Load https://news.ycombinator.com/item?id=20499467

  2. Tab/Shift+Tab until the "Hacker News" link at the top of the page is focused

  3. Launch Accerciser and in its tree of accessible objects, select the table row with the name "Rechargeable vs. Alkaline Batteries"

  4. 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.

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.....

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.

Blocks: texta11y
Priority: -- → P3

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.

(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.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.