Closed Bug 18934 Opened 26 years ago Closed 26 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: 26 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: 26 years ago → 26 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.