376369 - Caret browsing to a text input using arrow keys should focus it

Status: RESOLVED DUPLICATE of bug 260668

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

Description

[Mats Palmgren (inactive)]

Spawned off from bug 311376 comment 62 and 63.

Caret browsing to a text input using arrow keys should focus it, to allow
text to be entered.

STEPS TO REPRODUCE
0. turn on caret browsing (use F7 key or set "accessibility.browsewithcaret"
   preference to "true" manually in about:config)
1. load URL
2. click on the page background
3. using the arrow keys only - navigate to the text input
4. type something

ACTUAL RESULT
Text is not entered into the input (typing ' or / triggers FAYT).
Workaround: do a mouse click on the text input or TAB/Shift+TAB

EXPECTED RESULT
The text input should gain keyboard focus when the caret is inside it.

PLATFORMS AND BUILDS TESTED
Bug occurs in Firefox 1.5.0.11, 2.0.0.3 and trunk on Linux.

Comment 1

[:Gijs (he/him)]

I'm new to a11y, admittedly, but I don't think this is a good idea. How do you propose the user gets out of the box? tab/shift-tab will focus the next control, not the text after it (and clearly we can't change that behaviour) and arrowing out doesn't work. The user will be stuck, and the next control might be a lot further down the page (or worse, at the top of the page/UI, if this is the last one).

Comment 2

[Mats Palmgren (inactive)]

(In reply to comment #1)
> How do you propose the user gets out of the box? 

Using arrow keys.  If one can move the caret into a text control using them,
then I think it's reasonable to use the same keys to move it out again.
(except if it's a selection movement of course...)

If the element doesn't gain kbd focus then I don't see the point of moving
the caret inside the text control in the first place.

Note that with the default UA stylesheet it's impossible to see whether a
text input has focus or not, other than the blinking caret.  I think it's
confusing to have a blinking caret in a text control that doesn't have
kbd focus and thus do not allow typing, and that ' and / triggers FAYT.

Comment 3

[Radek 'sysKin' Czyz]

Unfortunately what you're proposing is just as confusing as current situation - because there are two states of "editing a textbox", one from a mouse click (or tab) where you can't leave and one from caret navigation in which you can.

I propose to leave current behaviour as it is, but perhaps change the way it *looks* to make it obvious that caret-in-a-textbox is not the editing caret and box is not focused. Currently the two states look identical, at least on windows.

Also, enter could focus the text box, much like it currently follows links.

Comment 4

[Jean-Michel Reghem]

setting platform all as it occurs also on vista

--> as the carret can be placed inside the text area with arrows and navigate also inside it, i believe that enter must at minimum give the focus to it ...