67907 - tab does not work inside textarea

Status: RESOLVED DUPLICATE of bug 2083

(Core :: Layout: Form Controls, enhancement)

Description

[Boris Zbarsky [:bzbarsky]]

BUILD: Linux 2001-02-06

STEPS TO REPRODUCE:
1) find a page with a textarea (any bug page will do)
2) click on the textarea
3) hit tab

EXPECTED RESULTS:
cursor moves to the right a few spaces

ACTUAL RESULTS:
nothing happens (cursor stays in textarea, does not move)

ADDITIONAL INFO:
This works as expected in build 2001-01-28-06.  It is broken in 2001-01-28-21.

Comment 1

[Warner Young]

Hmm, on NS 4.x, typing tab in a text field causes the focus to shift to the next 
text field or link on the page.  In Mozilla, this seems to be working the same 
on most of the text fields (e.g. Summary, Status, keywords), but not the 
Additional Comments area on this page.  Maybe only fails on multi-line text?  I 
tried this with build 2001020604, win98.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yep, that's the behavior on Windows.  On Unix, ns 4.x would insert a tab into
the textarea if you hit tab.

Now I don't care whether it inserts a tab or tabs over to the next field, but it
should not be doing nothing.  :)

Comment 3

[rods (gone)]

reassigning

Comment 4

[Tony Garnock-Jones]

This bug came up during the most recent BugDay... thanks, bz, for filing it for
me :-)

Just thought I'd vote for "actual insertion of a literal tab", the way it has
been in NS 4.x and Mozilla up until fairly recently (eg. late December builds,
poss. early Jan builds).

It'd be great if, say ctrl-tab, took you to the next field, but insertion of
literal tab makes editing text documents in a TEXTAREA that much easier (eg.
consider editing WikiWiki pages, where literal tab vs. a number of spaces makes
a difference to the format of the resulting page).

Comment 5

[Kathleen :Brade]

This is a duplicate of a bug...  Pick one of the following (or maybe another 
bug?):
  #2083   (tab in a textarea should change focus)
  #66285  (specification for tabbing)
or
  Resolve this as WONTFIX

Comment 6

[rubydoo123]

how about 2083

*** This bug has been marked as a duplicate of 2083 ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

This is not a duplicate of 2083.  The issue is that not only does the textfield
capture tabs, nothing is done with the captured tabs.  The textfield used to at
least insert the tabs into whatever you are editing.  Now there is absolutely no
response of any kind at all to a tab.  While bug 66285 is being discussed, it
would be nice if the functionality that used to be there were restored.  Note
that the bug was introduced sometime on 2001-01-28 -- it is fairly recent.

Adding regression keyword and reopening.

Comment 8

[rubydoo123]

remarking as dup of 2083, tab in textarea should jump to next form element

*** This bug has been marked as a duplicate of 2083 ***

Comment 9

[Kathleen :Brade]

perhaps this is really a duplicate of bug #29086 (need a keybinding to enter a 
tab)?

Comment 10

[Tony Garnock-Jones]

I'd second that, looking at the original bug report back up at the top. It's
definitely more a dup of bug 29086 than of bug 2083. ("Expected results: cursor
moves to the right a few spaces")

Comment 11

[rubydoo123]

tabbing within the textarea will no doubt jump to the next form element and will 
not probably not produce a tab sequence.