Last Comment Bug 376369 - Caret browsing to a text input using arrow keys should focus it
: Caret browsing to a text input using arrow keys should focus it
Status: NEW
: access, top100
Product: Core
Classification: Components
Component: Keyboard: Navigation (show other bugs)
: unspecified
: x86 All
: -- normal with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://www.google.com/
Depends on:
Blocks: caretnav
  Show dependency treegraph
 
Reported: 2007-04-03 09:42 PDT by Mats Palmgren (:mats)
Modified: 2010-04-21 13:03 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Mats Palmgren (:mats) 2007-04-03 09:42:06 PDT
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 Kruitbosch (away 26-29 incl.) 2007-04-03 09:53:49 PDT
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 (:mats) 2007-04-03 10:42:14 PDT
(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 2007-04-03 18:06:53 PDT
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 2007-04-04 01:02:20 PDT
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 ...

Note You need to log in before you can comment on or make changes to this bug.