Closed Bug 18934 Opened 25 years ago Closed 24 years ago

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

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 29086

People

(Reporter: bugzilla, Assigned: rubydoo123)

Details

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.
Assignee: troy → pollmann
Component: Layout → HTML Form Controls
Assignee: pollmann → buster
Severity: normal → minor
OS: Linux → All
Hardware: PC → All
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.
Status: NEW → ASSIGNED
Target Milestone: M14
fairly simple matter of deciding what we want to do, and telling the editor and
text control to do it.  marked M14.
Perhaps this behavior would be best when wrap="virtual", since
in that mode neither TAB nor CRLF should be returned to the server.
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
this was working last week, and now it's broken again.  anybody know anything 
about it?
moving non-PDT+ M14 bugs to M15.
Target Milestone: M14 → M15
The latest behaviour in Win32: Pressing tab in textarea writes a tab in the
field *as well as* moves to the next field!!!

This happens on Linux too, today's build.
This bug is on a collision course with bug 29086. CCing lake.

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.
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
> cripples functionality - you can't enter a Tab character into a textarea.

you already can't add a tab character into a textbox...
moving non-critical bugs to M17
Target Milestone: M16 → M17
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 
tabs.

Gerv
Reassigning to beppe (editor).
Assignee: buster → beppe
Status: REOPENED → NEW
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
this is a dup of 29086

*** This bug has been marked as a duplicate of 29086 ***
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Verified duplicate.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.