bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

textarea [TAB] should move to next field, not 6 spaces.




Layout: Form Controls
19 years ago
18 years ago


(Reporter: bugzilla, Assigned: rubydoo123)



Firefox Tracking Flags

(Not tracked)




19 years ago
The tab key should move to the next field (like it does
with every other widget).  Having it move three spaces
ahead is of little value; and not moving it to the next
field means that a mouse is required to leave a
textarea wiget, which is bad for data entry personell.


19 years ago
Assignee: troy → pollmann
Component: Layout → HTML Form Controls


19 years ago
Assignee: pollmann → buster


19 years ago
Severity: normal → minor
OS: Linux → All
Hardware: PC → All

Comment 1

19 years ago
When [Tab] is pressed in a textarea inside of Nav, Nav places a Tab character in
the textarea.  Not allowing this cripples functionality - you can't enter a Tab
character into a textarea.

IE 5 decided to take the approach suggested here and a [Tab] moves to the next
field.  Since this is a textarea widget issue, I'm forwarding this along to
Steve.  Steve, can you take a look at this and see if it's something you think
we should/can do?  Would this require changes in editor land?  I can update
nsGfxTextControlFrame::HandleEvent, but I get the feeling more is required here.


19 years ago
Target Milestone: M14

Comment 2

19 years ago
fairly simple matter of deciding what we want to do, and telling the editor and
text control to do it.  marked M14.

Comment 3

19 years ago
Perhaps this behavior would be best when wrap="virtual", since
in that mode neither TAB nor CRLF should be returned to the server.

Comment 4

18 years ago
4.7 works like this:
windows - moves to next control
mac and linux - inputs spaces in the text area

For mozilla, I voted for browser interaction over editor functionality, so tab 
key moves the focus to the next form element.  There is an easy workaround for 
getting the spaces in the textarea: just use the space key.  There must be a 
keyboard-triggered way for navigating form elements, and this seemed the most 
straightforward.  We can change this decision if there is public outcry.  We 
could even make it a pref, though I would rather not bloat the prefs that way.

Fixed in M13.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 5

18 years ago
I believe this problem is related to 2642 (tabbing problem between textarea 
fields). That report has been reopened so I will reopen this as well.
Resolution: FIXED → ---

Comment 6

18 years ago
this was working last week, and now it's broken again.  anybody know anything 
about it?

Comment 7

18 years ago
moving non-PDT+ M14 bugs to M15.
Target Milestone: M14 → M15

Comment 8

18 years ago
The latest behaviour in Win32: Pressing tab in textarea writes a tab in the
field *as well as* moves to the next field!!!

Comment 9

18 years ago
This happens on Linux too, today's build.

Comment 10

18 years ago
This bug is on a collision course with bug 29086. CCing lake.

Comment 11

18 years ago
Tabbing any where on a web page should move the focus to the next item in the 
web page for Windows, for Mac, and for Linux. Usability and UI design agree that 
this the 90% case for web page use. Additionally it enforces consistent behavior 
on using the tab key for navigation and is the most typical expected behavior. 
Alternative key strokes are being considered for Tabbing with in fields. For 
non-web page items this may not be the case but that is not what this bug was 
opened for.

Comment 12

18 years ago
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16

Comment 13

18 years ago
> cripples functionality - you can't enter a Tab character into a textarea.

you already can't add a tab character into a textbox...

Comment 14

18 years ago
moving non-critical bugs to M17
Target Milestone: M16 → M17

Comment 15

18 years ago
I think Tab should actually do different things depending on the context. For 
example, in HTML TEXTAREAs (bug 29086) it makes sense for Tab to be used for 
navigation and Ctrl+Tab for entering a tab character, since navigation is the 
more common operation.

But in places like plain-text Composer, it probably makes more sense for Tab to 
insert a tab character instead, since navigation is not so much of an issue 
(Ctrl+Tab can be used, as in 4.x, to navigate between body and headers).
Current Win95 behaviour: Tab moves to next field and inserts a tab. However, on 
the fields on the Bugzilla Helper, the first tab is one space, the next ones are 
eight... I assume this bug is tracking the issue that it shouldn't insert said 


Comment 17

18 years ago
Reassigning to beppe (editor).
Assignee: buster → beppe
buster & Lakespur are correct. On HTML forms, TAB should move to next form 
control on all platforms. This is important for disabled accessibility. 

If 4x behaved differently on Mac and Linux, that was a bug.

html32 form handling. nsbeta2 6/1-.
Keywords: nsbeta2

Comment 19

18 years ago
this is a dup of 29086

*** This bug has been marked as a duplicate of 29086 ***
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 20

18 years ago
Verified duplicate.
You need to log in before you can comment on or make changes to this bug.