1739597 - Accessibility: enabling caret navigation should move the focus into the DOM content

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[Valentin Villenave]

Open a web page (e.g. http://example.com), hit F7 and the “Yes” button.

Now hit any of the arrow keys, or PageUp or even <shift>arrow:
nothing happens. That’s because the focus is still actually on the
parent element, not in the actual DOM tree where you can select
and navigate.

Hitting F6 or whatever won’t help: there is no key combination, to
my knowledge, that allows you to access the child elements. (Of
course, most screen readers provide navigation functions that can
mitigate that lack.)

The only solution AFAIK (short of using the mouse) is to hit Tab and
hope that the page contains any user-interactable element such as
a link or a text box, which will indeed enable you to get the focus at
a lower level and from there start moving the caret around with the
keyboard. If the page happens not to contain any such element, you’re
out of luck.

This is actually a very old regression, which I tracked to Nov. 25, 2014:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=be4ba3d5ca9a&tochange=74edfbf0e6a3
Prior to that, one could hit F7, confirm and then immediately start using
the arrow keys.

I couldn’t find any duplicate as part of bug 241023 though, so I’m unclear
as to whether this was actually a deliberate change in behavior or not.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Got a cold so that using sick leaves)]

When caret browsing is enabled, nsFocusManager::UpdateCaret() is called. nsFocusManager::MoveCaretToFocus() does nothing except removing all ranges since there is no focused content if I type F7 immediately after loading the page from the URL bar. Finally, nsFocusManager::SetCaretVisible() is called, but it does nothing special except updating caret state. So that it looks like that nobody takes responsibility for activating the document.

S3 for now because of the workaround. But this may be S2 for the users who require the caret browsing mode.

(Oddly, I don't find the regression point from the commit log.)

Comment 2

[Valentin Villenave]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #1)

S3 for now because of the workaround. But this may be S2 for the users who require the caret browsing mode.

Well, the workaround only works when there’s a link or a Tab-able element in the page.
I don’t know if it’s S2-worthy, but it’s definitely quite annoying compared to FF 33.

(Oddly, I don't find the regression point from the commit log.)

I couldn’t either. Since taskcluster didn’t work back then, could mozregression be off by a day or two in either direction?