Open Bug 29086 Opened 25 years ago Updated 1 month ago

keybinding needed to enter \t (tab) in multiline textfield (textarea)

Categories

(Core :: DOM: Editor, enhancement)

Product:
Core
Component:
DOM: Editor
Type:
enhancement

Tracking

()

Milestone:
Future

People

(Reporter: elig, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: access, Whiteboard: relnote-user)

Attachments

(1 file)

For all of you who want tab in textareas here is a little patch. This might be against the mozilla specs, but the way mozilla does it is against my brain's specs ;-)
1.71 KB, patch
Details | Diff | Splinter Review 
* TITLE/SUMMARY
Tabbing within TEXTAREA removes focus from text field

* STEPS TO REPRODUCE
0) Launch Apprunner
1) View the Bugzilla bug submission page
(http://bugzilla.mozilla.org/enter_bug.cgi?product=Browser)
2) In the description field, type some text, press the tab key, and press the
space bar.

* RESULT
 - What happened

Oops! You've just accidentally submitted your bug, when you meant to merely move
your editing caret. (fortunately, you didn't fill out the required fields, so no
bug was really submitted.)

Rather than inserting a tab into my text entry, the focus changes to the push
button immediately following the textfield.

 - What was expected

My off-the-cuff feeling is that a multiline TEXTAREA field on Mac OS should
interpret a tab as an acutal tab, rather than as a focus change.

On a deeper level, I haven't looked at hundreds of forms on the web to see how
this would affect their keyboard navigation, so I don't really know. IE 4.5 will
change focus to the next textfield on the page.

Although obviously not using HTML forms, MT-Newswatcher is smart enough to
assume that users who press tab in a one-line text field wish to go to the next
field --- whereas users who press tab within their posting (a large TextEdit
field?) actually wish a tab to be inserted.

I've CC:'d German and a few fellow Mac weenies in case they have comments. (Hi,
Mr. Masri. ;)

* REGRESSION

 - Occurs On
        Mac OS Apprunner (2.24.00 optimized build)		

 - Doesn't Occur On
        Win32 Apprunner (behavior is consistent with platform standards)
        Communicator 4.72 (some pre-RTM build)




* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
[QA Assigning to self, since I have a personal interest in the issue.]
QA Contact: sujay → elig
Keywords: pp
Thanks for cc'ing me. We keep meeting like this... :)

Communicator 4.7 follows Mac HIG correctly. When you hit tab in a single-line 
field, you tab to the next text field. When you hit tab in a multi-line TEXTEDIT 
area, you insert a true tab. There may be legitimate reasons why one would want 
to insert a tab into a TEXTEDIT field; disabling this ability would be a mistake, 
IMO. Besides, this matches behavior on previous browsers. And, if websites don't 
want tabs, they should be stripping all illegal characters out from the submitted 
form anyway.

I don't know if this is HIG-compliant on other platforms.

- Adam

masri--I can't find your references in my copy of Apple HIG.  My copy (page 276)
says:  In text-oriented applications, the Tab key is uesed to move the insertion
point to the next tab stop.  In other contexts, Tab is a signal to proceed: it
signals movement to the next item in a sequence.  Since this isn't a word
processor, I'm not sure that <textarea>s should insert a /t or some number of
spaces or do the navigation as it currently does.

I think that the above quote from Apple HIG could be interpreted either way.
Does someone have a newer version of Apple HIG?

The HTML 4.0 spec doesn't provide much guidance either though they do have use
the following as an example:  "...the 'tab' key is used for navigation and the
'enter' key is used to activate a selected element"

To me, it's pretty clear that if we want to be html 4.0 compliant, we need to
provide *a* key/keyCombination to navigate across the required elements (a,
area, button, input, object, select, and textarea).  Does anyone want to suggest
a key if we aren't going to use Tab?

Reassign bug to German for his decision.
German--please reassign to me when you decide how we want to handle this.
Assignee: brade → german
Convention in Mac applications is to have Command-tab tab you out of a text area 
that can itself receive tab keys. Shift-command-tab should also let you tab 
backwards out of a textarea.

I don't think this is pp. I'm pretty sure it's standard behavior in MacOS, 
Windows, and Motif (and probably GTK as well). Unfortunately, neither Apple nor 
Microsoft seem to mention it specifically in their UI guidelines.

And it should apply to all XPFE multi-line text boxes, not just those in HTML 
content.

Here's how it works (on MacOS, for `Ctrl' read `Command'):

* Ctrl+Tab = navigate to next control, for all controls
* Tab = navigate to next control, for all controls except multi-line text boxes
  (in multi-line text boxes, = insert tab)

* Ctrl+Shift+Tab = navigate to previous control, for all controls
* Shift+Tab = navigate to previous control, for all controls except multi-line
  text boxes (in multi-line text boxes, = insert tab)

This is consistent with the other thing unique to multi-line text boxes, which is 
the result of pressing Return/Enter:

* Ctrl+{Return/Enter} = activate default dialog button (if it exists), for all
  controls
* {Return/Enter} = activate default dialog button (if it exists), for all
  controls except multi-line text boxes (in multi-line text boxes, = insert line
  break).
Keywords: 4xp
mpt, command-tab on MacOS 9 causes a cycle through currently running programs (I 
believe this is a new feature of MacOS 9, and it's certainly one I didn't know 
about, so uh, thanks. :)  ). Control-tab and option-tab on MacOS Communicator 4.7 
simply inserts another tab; it doesn't tab to the next field.

Communicator 4.7's behavior is to insert a true \t when the user hits the tab 
key. If you type a few characters, then hit tab, it's very obvious it is NOT 
inserting some set number of spaces. it is inserting a true tab stop.

I cannot find a particular description of this wanted behavior listed anywhere in 
the HIG manual. However, HIG also doesn't specifically DISALLOW this behavior. Do 
we really want to bar the user from typing a true \t in a textedit field, when 
that might be precisely what they wanted to add? There may be a legitimate reason 
to have a \t in a text field, such as a CGI form that takes text from a field and 
automatically builds a web page from it, complete with indents. Well-written CGIs 
that didn't want the \t should automatically parse all that stuff out when the 
form is submitted. And they must be doing this, because this is allowed behavior 
on Communicator 4.7, which means at least 50% of Internet users now have the 
ability to put a tab stop in a form.

Once again, this falls back to Mac HIG: if you're adding features to your 
application that do not specifically violate HIG, and make the application more 
pleasant to use for the user or yield "expected" behavior, then the addition is a 
good idea. Therefore, since no violation of HIG is occuring by having this 
feature, I'd suggest that tab insert a true tab stop (not spaces), and control-
tab be used to tab out of the multi-line TEXTEDIT field.

- Adam

Actually, Command-Tab has been in MacOS since 8.0, and I should have realized I 
was creating a clash. Whoops. (In my defence, I took sfraser's claim at face 
value, and didn't check it myself; it turned out to be wrong, at least for MacOS 
8.0 and upwards.)

Other MacOS apps aren't helpful for precedents here.
* Communicator 4.x: there's no way of getting out of a multi-line text field with
  the keyboard at all, which is bad news.
* MacOS Finder > File Info > Comments field: Tab takes you out of the field, and
  there's no way of inserting a tab.
* MS Office 98 > File > Properties > Comments field: Tab takes you out of the
  field, and there's no way of inserting a tab.

Perhaps we should treat {inserting a tab character} as the special case, rather 
than {tabbing out of a multi-line text field} as the special case. In my years of 
using the Web I can't remember ever wanting to insert a tab character in a text 
field. So presumably if someone wants to do it, it's rare enough that they'll be 
willing to do something slightly more complicated than using the naked Tab key.

So why don't we make Ctrl+Tab (not Command+Tab) the key sequence -- on all 
platforms, including Mac -- for inserting a tab character in a multi-line text 
field? Then we can make Tab the key for going to the next field in *all* widgets, 
and this bug can be resolved wontfix.

>Other MacOS apps aren't helpful for precedents here.



Consultant, a Mac PIM, has a useful precedent here. In the comments field of a 

contact form, hitting tab does not move you back to the first field again. It 

inserts a true tab (not spaces). Command- or Option- or Control-tab do not move 

you to a different field.



Database applications also typically work this way, where a tab in a multi-line 

text field will indeed insert a \t . The applications you listed are poor 

examples, because there is no legitimate reason to need to insert a tab in those 

multi-line TEXTEDIT areas. There IS a legitimate reason to insert a \t in a 

TEXTEDIT field in Communicator for the reasons I previously outlined.



>So presumably if someone wants to do it, it's rare enough

>that they'll be willing to do something slightly more

>complicated than using the naked Tab key.



This would change established norms of HIG (at least on the Mac platform), which 

would be a very bad idea. We would be wiser to use tab for its intended purpose 

in multi-line TEXTEDIT fields, and use the special case (ctrl-tab) to move 

outside a multi-line TEXTEDIT field.



- Adam


Ok, use Ctrl+Tab/Ctrl+Shift+Tab as something which navigates out of all gadgets, 
on all platforms, and Tab/Shift+Tab as something which navigates out of all 
gadgets, *except* multi-line text fields, on all platforms. Everybody happy?

(BTW, you can't refer to the Macintosh HIGs as if they support either one view or 
the other, because they don't -- unless a multi-line text field is a
`text-oriented application' and a single-line text field is not, which is a 
pretty dubious claim to make.)

This bug is on a collision course with bug 18936. CCing lake.

It would make life a *whole* lot easier if we just forgot about being able to 
enter tab characters in multi-line text fields. Can anyone, anyone, give me a 
single example where this would be useful on the Web or in Mozilla's chrome? Not 
HIG-compliant (which isn't that relevant, since Mac doesn't have full keyboard 
navigation for widgets anyway), but actually *useful*?

I encounter this problem daily when submitting bug reports. (Granted, that usage 
of multiline text fields is not representative of what most people use browsers 
for.)

mpt, I think I already gave potentially useful examples of where this would be 

required. Example: a CGI that automatically posts news items that a user could 

submit to a web page, with indents for each news item. Example: getting a web-

based interface to modify a tab-delimited text file that is used by a web-based 

application on systems that don't allow telnet access. Those are just the first 

two that pop up in my mind. I'm sure if we all sat here, we could think of lots 

of reasons to not disable the ability to add a true \t.



One of the things specifically covered in HIG is that when you have the choice 

between:



1) disabling an expected behavior to include a useful feature, or

2) implementing a useful feature in a way that may not work on all systems, 

without disabling expected behaviors



you always pick 2. Precedent? The original Mac (128/512/+) keyboard had no 

control key, while later systems (after the SE was released in 1986 or so) did. 

There were applications that would require the use of the control key; these 

applications would have to be changed, because forcing the user to use that key 

disabled an expected behavior of the application. On the other hand, implementing 

a useful feature using a key not available on all keyboards (like function keys 

or the control key) is perfectly acceptable, as long as there's another way to 

access that function on systems w/o all those keys present (a menu item, dialog 

box, etc). Then, you haven't disabled the behavior, you've simply made it 

slightly more difficult to access (requiring the use of the mouse, perhaps).



Therefore, my expectation is that Moz follow current conventions of Communicator 

4.7, and allow tabs in textedit areas. If the user wants to tab out of a multi-

line textedit, they can either use the mouse, or a useful addition we add for 

them (like control-tab, or something else that doesn't conflict with another 

expected behavior as command-tab would). If this violates some section of CSS, 

then CSS is wrong and should be modified. Why would we want to disable features 

that someone might need?



- Adam


This bug has an additional component that I didn't include in the original
report, probably because UI objects don't return to an unfocused visual state,
so I thought nothing of it. ;)

Namely, on this morning's Mac OS build, if you:
 - go to a bug report, and type "foobar"
 - place the editing caret in front of the word "foobar"
 - press the tab key

...the focus will move to the next form object, *and* the word "foobar" will
have a tab inserted to its left.

beppe & petersen are seeing this on Windows, but are unable to reproduce on the
same Mac build running on the same OS.

>There may be a legitimate reason to have a \t in a text field, such as a CGI 
>form that takes text from a field and automatically builds a web page from it, 
>complete with indents. Well-written CGIs that didn't want the \t should 
>automatically parse all that stuff out when the form is submitted.

Huh?  Just because some browsers don't let you put tabs in, all CGI scripts 
should strip them out?
Changing summary of this bug so that we have "moz should x instead of y" 
and "moz should y instead of x" instead of "moz x's" and "moz should x instead 
of y", which is confusing.
Summary: Tabbing within TEXTAREA removes focus from text field → Tab in TEXTAREA should insert \t instead of switching fields
davidr, how could you read all the comments in this bug report, and then come to 
that conclusion? That's not what I'm saying at all. What I'm saying is that if a 
CGI needed a \t , and we disabled that ability for Moz to produce one in a text 
field, then that's bad. If a CGI doesn't want a \t , and Moz produces one (due to 
the operator typing one), that's perfectly ok, because CGI's are generally built 
to disregard input they don't want to see anyway.

- Adam

I saw another bug report where basically the opposite problem was reported 
elsewhere in the browser.

My own take on this is that it should be a prefs option.  Those who are used to 
NS/IE behavior can leave that as a default (Tab, regardless of the field, 
switches to next field [and should switch to the address bar if that's the next 
field! See bugs 33069, 36278, 31809]), while those who prefer a more 
editor/wordprocessor-like behavior can pick a select box that changes the 
behavior to insert tab instead of change focus, in a multi-line text field. You 
could even allow them to insert tab in a ONE-line field, if they so desire. An 
adjunct to this would be to make Cmd-Tab (Ctrl-Tab for Windows people, I guess) 
1) insert a tab, regardless of field length, if the user's prefs are "Tab 
changes focus always" or 2) shift focus to next field, if user's prefs are "Tab 
always inserts a tab". If the user's picked "Tab shifts focus except in a 
multiline field", Cmd/Ctrl-Tab could be either way, depending what they want it 
to do. 

PS: I'd strongly advise against making Tab do anything other than tabbing for 
shifting focus, such as inserting x number of space characters.  If I wanted to 
insert 5 spaces, I'd hit Sp
That is a good suggestion and I agree with you on the default. Now we get to the 
other problem of getting it into the prefs. I'll suggest it to the Prefs people 
and designers. 
I feel that for the web as it currently is used and for the forseeable future 
going to the next field will be the 90% case for most web sites. There are few 
cases where high end editing is required.
lake,

>I feel that for the web as it currently
>is used and for the forseeable future 
>going to the next field will be the 90%
>case for most web sites.

And I think I've proven multiple times in a row that you are 1) removing 
functionality and 2) not following current Communicator behavior. But I'm sure 
that your countless hours of intensive usability testing have confirmed that your 
suggestion is the correct one.

On this, we agree to disagree. 

- Adam

It should be a prefs option? Ha ha, very funny. You would have added the
UI/bloat/support track/confusion required for another pref, and you wouldn't have 
solved much because most people wouldn't even realize the pref existed.

I know it hurts, but sometimes you have to actually Make A Decision (!) about 
which behavior to use. One or the other.

I'm sticking with my recommendation of Tab to insert tabs, Ctrl+Tab to get out of 
TEXTAREAs -- mainly because if you were going to write a document with a lot of 
tabs, pressing Ctrl+Tab each time would be annoying (much more annoying than 
having to occasionally press Ctrl+Tab instead of Tab to navigate between items in 
a page).

mech@eff.org: as already described in this report, Cmd+Tab is reserved for 
switching between applications. This would be Ctrl+Tab only.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Adam--I don't think we would be removing functionality if you couldn't insert a \
t by pressing the tab key.  You could still paste the character into the field if 
that is what you truly wanted.

Is it true that all platforms of 4.x Communicator allow you to insert a tab by 
pressing the tab key?

Personally, I find it *VERY* annoying that I can't move to the next field from a 
textarea (or the previous field).  

I think for consistency and standards compliance, we should use the tab key for 
navigation only and set control-tab or some other combination to do insertion of 
tabs (since far fewer people will want to insert tab characters).  My 
interpretation of the html 4.0 standard is that we need to provide *1* keybinding 
to do forward navigation.  You can't change the keybinding in the middle.  That 
would truly suck if you were visually impaired and didn't necessarily know you 
were in a textarea as opposed to a single line input or button.

My vote is for tab as the universal keybinding to navigate forward for beta2 and 
see how many people complain about not being able to insert tab characters in 
textareas.

By the way, why is a textarea special? why can't I insert tab characters in 
single line inputs?

mpt, you (justifiably) complain that some people wouldn't be able to find a 
pref, but what about the people who can't figure out that ctrl-tab exits a 
textarea?

another point: internet explorer lets you tab out of a textarea.  any cgi that 
requires tabs probably has already given its users an extra way to input them, 
perhaps by putting a literal "\t" in or by putting in a fixed number of spaces.
"You could still paste the character into the field if 
that is what you truly wanted."

And exactly how would one do that, especially one who is not that familiar with 
the web or GUIs anyway? An onscreen button on the webpage, which takes up 
unnecessary space and forces the page designer to screw around with JavaScript? 
You certainly aren't thinking that they use an ASCII code to text translator 
program, copying the character into the clipboard, then pasting it into the 
document? Gee, that's improvement.

"That 
would truly suck if you were visually impaired and didn't necessarily know you 
were in a textarea as opposed to a single line input or button."

That is a totally specious argument. Visually impaired people are NOT going to be 
using Moz to do ANY kind of surfing. They will be using Lynx and speech synthesis 
software. Engineering has seen to that-- since you aren't using native UI 
widgets, any software that can control the UI for the visually impaired will not 
operate with Communicator, since none of its controls are actual UI components 
anyway. And frankly, I don't see the point of hardwiring anything into the 
source. More likely, some of the parsing routines of Moz will make their way into 
Lynx at some point in the future, so Lynx can view newer types of webpages. All 
the UI features in the world are useless to a visually impaired user.

"By the way, why is a textarea special? why can't I insert tab characters in 
single line inputs?"

This is more a historical issue than anything else. In the early days (1984), the 
only consumer-viewable GUI ran on a Mac 128K with a 512x384 pixel screen. You 
didn't want to use any unnecessary space for onscreen buttons, and the entire 
point of a GUI is to use the mouse to do a lot of things (click where you used to 
type). One of the key tenants of good usability design is to always give the user 
a more efficient way of doing something they do repeatedly, without taking away a 
potentially desired ability (even if it isn't desired by you).

A single-line text field is normally dealt with the same way a field in a 
database or spreadsheet in text-based systems is dealt with. You enter text, and 
you move along to the next field to enter more. Because Apple's designers didn't 
want to break away with computing tradition (text based interfaces used tab to 
move to the next field), and they wanted the interface to mimic real-world 
devices the user had probably used (a typewriter, typing on a form, using tab to 
move from field to field), the tab key's job became movement from one field to 
the next, in places where inserting a tab didn't make sense.

In a word processor, you want the interface to "feel" like something they're 
familiar with (a typewriter), and a typewriter often has adjustable margins, so 
why not have the tab key do exactly what a typewriter would do-- kick out the 
cursor a certain distance, specifyable by the user?

So, now we get to a TEXTAREA. A TEXTAREA is a multi-line text field, like a word 
processor. Does it always make sense to insert a tab? No. As I discussed 
previously, it totally depends on the usage of the field. In a notes field in the 
Finder, or in many popular PIMs, the designers decided that tabs make no sense in 
a notes field. Most likely, the desired operation would be to move out to the 
next field. If the user wanted an indent, they can hit the space bar a couple 
times. Also, many other PIMs either don't have notes fields, or any kind of tab 
insertion would screw up a tab-delimited export/import operation. Best to stay 
away from tabs in these cases.

So why do I see Moz being a bit different? Because Communicator is an interface 
to applications running on other computers, and Moz will be too. Whatever you 
want to call Moz (a browser, a web-based application development environment, or 
any other marketing speak), that's what it is. And the ability to insert a tab 
into a foreign computer program may be a necessity, or may be the basis for some 
new program we haven't seen yet.

I think adding yet another prefs option is idiotic. You absolutely must make a 
decision on this issue. But you need to make one that conforms to good UI design 
principles: give the user the ABILITY to have a keyboard shortcut, without taking 
anything away from them. And if you think about the permutations of different 
keyboard-based shortcuts, the only one that makes any sense is to allow the tab 
key to insert a true \t, and control-tab to move out of the field. The user can 
still use the mouse, if they didn't know the shortcut. You haven't taken anything 
away from them. The opposite is not true: for the user that doesn't know the 
shortcut, they can't insert a \t if that was desired. You're forcing the user to 
learn new things about your program's UI at gunpoint, instead of allowing the 
user to learn keyboard shortcuts over time, as their proficiency increases.

I think this is one reason why Mac users hate PC/Win/UNIX users so much. Since 
these users grew up with the keyboard and text-based shells, they expect there to 
be a keyboard way to do everything at the expense of good UI design. Mac users 
want a beautiful, functional UI first and foremost-- worry about the keybaord 
shortcuts later. Different philosophy.

- Adam

Ok I think we have gotten to the point where more discussion won't really get us 
an where but I'll give it one more try. I agree that there should be a way to 
put a tab into a text field. I have always agreed with this. There should be an 
obvious way to navigate out of a field with out using the mouse. Where we 
disagree is on how this is to be done. Am I right?

Our two proposals for are: 
Tab to enter a Tab and Ctrl+Tab to go to the next field.
or
Tab go to the next field and another Ctrl+ (Tab or alpha numeric) to enter a 
tab.

(Here we should note some current 4.x behavior on the PC. Ctrl+Tab cycles 
through open 4.X windows even in a multi line field) My survey of Keyboard user 
showed that this was a valuable feature I don't want to take away from this 
functionality these people use it every day and many times per day on different 
applications and websites. 
On the other hand Mac does things differently. and it works for them. Should we 
consider making the mac version different? Possibly. Should we make every thing 
behave like the Mac? ... Especially when a good deal more people are now used to 
the PC it's probably not a good idea.
But before we get into a new can of worms.

Lets consider the user, You know the ones that can't find the prefs and just 
want to get their work done, they don't read help and like that. 
They are happily tabbing away possibly they come accross a comments section in 
the form they are filling out. They don't have any comments so they want to move 
on. They hit Tab and they start looking for the focus.... "not there"... "may be 
it didn't hit it" they think... (users try again when something they expect to 
work does not. I have lots of tapese of this if you want to see one I got just a 
 few weeks ago) After a little of this maybe they get frustrated maybe they 
try finally look back in the multi line text field... Finally they see the 
flashing cursor in the middle of the field? "How did that get there?" they may 
well wonder. Then if they get it that a Tab incerted a "Tab" the next natural 
reaction is... "OH I guess tab doesn't work here How do I get out of this 
field? I have to use the mouse." This is what we call a failure in the Utest 
Field. 

Now lets take hypothetical the user to another situation where they want to 
enter the comments in the field... They Tab over to the multi line field and 
start typing and want to indent or enter a Tab they Press Tab and it goes to the 
next field.. "Where did my cursor go? OH but I wanted a Tab...I guess Tab still 
Tabs to the next field." they Shift Tab back to the field and try again to 
indent...if Tab doesn't work it is not likely they will know that Ctrl+Tab 
enters a tab but they do know Tab takes them to the next field. "So I guess I 
have to enter some spaces instead". They can still complete the form with out 
using the mouse. yes this is inconvenient and it does cause some errors but they 
are still able to get the task done. (Not using the mouse is a W3C 
WAI requirement not a suggestion)
(Also there was some work on a floating palet that works for formating HTML text 
so they can select a few lines and the pallet will let them indent, change the 
color, and all that in a multi line text field on a web page. 

You can site guidelines and good UI behavior but if it confuses the user or does 
not serve the user is it really the right way to go? Guidelines are just that 
guidelines and they are not laws and they do not cover every instance of UI.

Another note here is that Blind and visulally impaired users do use Netscape and 
IE. They use it with a screen reader like JAWS or MAGic. They "Look" of the UI 
is irrelivent To JAWS users but the keyboard operation is the same. So brade's 
statement of use for usually impaired is valid. Tab use consistency (not 
switching the out come of a tab press) is very importiant.

Another thing that is importiant for Netscape though not so much for Mozilla is 
the implications for this effecting our business with the government as they are 
required by law to provide for diabled employees appropriate tools to allow then 
to perform their job and of course not to discriminate based on disability. (Now 
I'm not saying changing tab behavior in multiline text fields totally disables 
the application for disabled users but given a choice and yes they still have 
one we could lose big money because of this.)


I agree too that need for consistent navigation traversing all keyboard 

navigatable fields is more basic than and overrides the need to insert tabs at 

certain occasions in text areas.

Thus I suggest as well:

tab -> always moves to the next field

shift tab -> always moves to the prev field

I agree with Matts statement that we should treat inserting tabs as the less 

common case.
Target Milestone: --- → M20
Well, one thing we do agree on is that we've reached the end of this discussion. 
Somebody actually needs to make a decision now.

"On the other hand Mac does things differently. and it works for them."

I would not be surprised that an audit of Windows and/or UNIX apps would find 
instances of the behavior I'm asking for where it makes sense. I doubt this is 
simply a "Mac" way of doing things, I believe this is a UI-conformant way of 
doing things.

"I have lots of tapese of this if you want to see one I got just a few weeks ago"

I had no idea you've actually done usability testing on this particular issue. 
So, I apologize for my totally smartass comment. Did you only do these tests on 
Windows? I know that Windows represents a majority of the desktop systems in 
existence, but what I find unfortunate is that most people I know who use Windows 
have a general disdain for GUIs anyway. It's too bad you didn't run your tests on 
a group of people who really like GUIs, to see if the same problems you ran 
across would happen to them. I doubt it, because they know how a good UI is 
supposed to act. My opinion of Windows has always been that since the users don't 
really like GUIs anyway, it's no wonder that the apps don't always conform to UI 
standards (and the users don't bother to complain about UI inconcistencies), 
which causes the users to not know what to expect of an application. If all your 
testing was w/Windows users, then no wonder your test subjects were so confused.

"They Tab over to the multi line field and start typing and want to indent or 
enter a Tab they Press Tab and it goes to the next field.. "Where did my cursor 
go? OH but I wanted a Tab...I guess Tab still Tabs to the next field."

Is that what you think would happen, or is that what you actually obsered in 
usability testing? Once again, adherence to a strong GUI standard would 
alleviate, if not outright dismiss, these types of failed expectations.

"if Tab doesn't work it is not likely they will know that Ctrl+Tab enters a tab 
but they do know Tab takes them to the next field. "So I guess I have to enter 
some spaces instead"

... Which totally fails the reason this bug report was entered in the first 
place.

I'd love to hear other people's options on how one would insert a real \t where 
it was needed. But in the end, it's engineering's call. Both situations are less 
than ideal. I know engineering is getting sick of ifdefs all over the code, but 
the way Mac users will expect the tab to operate is the way I'm outlining. So, if 
you're unwilling to have tab work this way on all platforms, then at least make 
it work this way on the Mac. This is the way Mac users expect a tab will operate.

- Adam

I have only read approx. one third of the comments of this bug, but I'd like
to say that I like the 4.x behaviour that the tab key in textareas really
inserts a tab, for the same reason elig@netscape.com mentioned: It is useful
in formatting bug reports, and I would really miss them.
I just wanted to mention that this bug's summary conflicts with bug 18934 
"textarea [TAB] should move to next field, not 6 spaces."
Bug 31232 is about the question how to write javascript for turning off 
the current "go to the next widget" functionality and replacing it by 
"insert a tab into textarea", which is in my opinion what most page 
designers would want for textareas. 

seems like a decision has been made; German--could you reassign this bug to beppe 
(without a milestone)?

Andreas Franke--for compatibility with the html4 standard we need to provide a 
key to navigate across all form elements; the decision is that this key will be 
tab in mozilla.  

Having read _all_ comments of this bug, I'd like to add some more notes:

First of all, I'm on Linux, have never really used IE, and currently
running Communicator 4.5 (and I like it). The behaviour for textareas 
is the following:

- Ctrl-Tab	always jumps to the next form control
- Tab		inserts a real tab in a textarea
- Alt-Tab	doesn't do anything 
- Ctrl-Alt-Tab	behaves like Tab in a textarea, and inserts a space 
		in a single line text field (maybe not very important...)

I'll try to summarize the main points as I see them.

"Should Tab in TEXTAREA insert \t instead of switching fields ?"
================================================================
Pro: 
- there should be an easy way to format texts in a textarea
  - everything but plain Tab would be really odd for this purpose
- backwards compatibility with 4.x

Contra:
- there has to be one key that always navigates to the next item
  - IE uses Tab for this purpose
  - Ctrl-Tab already has a job: switch between navigator windows
  - everything else would be really odd

My solution for all this (except compatibility with IE):
- Tab	    should insert a tab in a textarea
- Ctrl-Tab  should always navigate to the next field
- Alt-Tab   could switch between navigator windows (this would even make sense
	    because Alt-N is the shortcut for opening a new navigator window)

Since most people know about Shift-Tab, it should not be too difficult 
to find out about Ctrl-Tab (just another modifier). On the contrary, it 
would be really hard to use Modifier+Tab while editing text.
And if there is any reason why this is not possible on Windows,
it could still be implemented for Mac and Unix.

Well, I have to accept that the decision has been made, but since 
mozilla is open source, I should be able to hack my own version... :)
Actually, this may be a good starting point. Is it all XUL, or is it hardcoded
in C code?
Ok, in my previous comment I should have said that I was using fvwm95-2.
Unfortunately, KDE already uses the proposed Modifier+Tab keys:
- Ctrl-Tab switches between desktops
- Alt-Tab  switches between applications
Thus my simple solution wouldn't work under KDE, but switching 
between Navigator windows via Ctrl-Tab wouldn't work either... :-(

Actually, KDE uses the "Scroll Lock" key to swich on/off this predefined
behaviour of Ctrl-Tab and Alt-Tab (and maybe other keys).
Thus my solution would still work under KDE :-) 
I shouldn't have said that I like Communicator. It just crashed after I had
written quite a long comment here... :( Well, mozilla will be better.
Here we go again:

After some experimentation with fvwm95-2, KDE, Gnome and WinNT I finally have to
agree that it is a bad idea to mess around with Alt-Tab because all systems seem
to use it for switching between all application windows. The only exception is
fvwm95-2, which is not quite modern...

I tried out Ctrl-Tab with Communicator 4.7 on WinNT, and I'm really impressed.
It's a great feature! Since there are also other apps on Win that use this 
shortcut for the same purpose (e.g. CorelDraw), it should be kept, at least on
win. However, to be consistent, Ctrl-Shift-Tab should cycle through the 
Navigator windows in the reverse order. Currently 4.7 does something different,
which is bad.

So we're quickly running out of modifiers, at least on win, and we'll inevitably
arrive at Tab/Shift-Tab for tabbing through the form controls. That's why I
finally agree with the decision, at least for windows.

Ctrl-Alt-Tab also makes sense: it prepares to leave the site (as opposed to 
quit the application like Ctrl-Alt-Del does) by navigating to the location
field and selecting the complete URL, thus getting ready to replace it with
a newly typed one. Ctrl-Alt-Tab can be entered most easily using both hands,
but that's not a problem because you're expected to type something directly
afterwards anyway.

However I insist that there should be some way to enter plain tabs into a
textarea form control, even on win, and preferably by using the tab key
without any modifier. What about a possibility to switch to an ``edit mode''?
This could push the ordinary tabbing through form controls from Tab/Shift-Tab
to Ctrl-Tab/Ctrl-Shift-Tab, overwriting the ``Switch between navigator windows''
behaviour, while enabling both Tab and Shift-Tab to insert a plain tab in the
textarea field. The user should always know whether this ``edit mode'' is active
or not, so maybe one could use the "Scroll Lock" key for this (there is an LED
associated with it). 
As far as I can see, this would not violate the decision that has been made.
What would be the problems with this approach? Are there any major platforms
that do not have this key? Are there any problems with the detection of the
current state of this key? Would this cause any major usability problems?

Well, I'm commiting this now to avoid a second crash of Communicator...
So the final call is that the tab behavior should follow as in German's 05/02 
conclution. reassign it to beppe
Assignee: german → beppe
Eli -- is the tabbing behavior consistent across platforms? Does the use of the 
tab set focus to the next form element? In addition, does shift-tab reverse the 
selection?
Target Milestone: M20 → ---
Offhand, I have no idea. However, I'm sure that someone CC'd to this bug report 
could tell you. ;)

beppe -- yes, tab behavior is identical across platforms in Mozilla. Is that what 
you meant?

The reason the pp keyword is still there, I think, is because implementing this 
will involve a deviation from the usual XP mapping of (Windows Ctrl == Mac OS 
Cmd). Cmd+Tab is already used on MacOS, so Ctrl+Tab needs to be used instead in 
this case.

So German's decision can be interpreted thusly, for multi-line text widgets (I'm 
sure German will stop me if I'm wrong):

Action                  Windows, Unix  Mac OS
---------------------------------------------------------------
Move to next field      Tab            Tab
Move to previous field  Shift+Tab      Shift+Tab
Insert tab character    Ctrl+Tab       Ctrl+Tab (*not* Cmd+Tab)

Resummarizing to reflect this.
Summary: Tab in TEXTAREA should insert \t instead of switching fields → Tab in TEXTAREA -> next field; Ctrl+Tab -> insert tab character
Summary by Matthew Thomas is:
Action                  Windows, Unix  Mac OS
---------------------------------------------------------------
Move to next field      Tab            Tab
Move to previous field  Shift+Tab      Shift+Tab
Insert tab character    Ctrl+Tab       Ctrl+Tab (*not* Cmd+Tab)

I don't think this last item will work.  My understanding is that Ctrl-Tab is 
used to cycle through windows or applications or something similar (at least on 
Windows).  Do we have a different keybinding for inserting a /t?

OK every one. Shuang made the last call that German's 5/2/2000 statement is 
final. 

And the decision is: tab -> always moves to the next field

shift tab -> always moves to the prev field

He did not say except for in a multi line field. Ctrl+Tab in any case was not 
mentioned in the statement. Only that entering tabs shjould be treated as the 
less common case. And it is confirmed that Ctrl+Tab will be used for other 
purposes.

Entering a Tab into a field will be accomidated but not by Ctrl+Tab.
Well, ok, so if `Entering a Tab into a field will be accomidated but not by
Ctrl+Tab', then what *will* it be accommodated by? Without that key-binding being 
published, this bug as originally reported can't be resolved.
Summary: Tab in TEXTAREA -> next field; Ctrl+Tab -> insert tab character → In TEXTAREA: navigate = Tab/Shift+Tab; enter tab char. = ???
Matthew--good question.  Perhaps we should discuss in a newsgroup?  
(mozilla.editor newsgroup?)

assigning this over to rods -- Rod we need to make sure that the tab functions 
work accordingly:
Action                  Windows, Unix  Mac OS
---------------------------------------------------------------
Move to next field      Tab            Tab
Move to previous field  Shift+Tab      Shift+Tab

I am recommending that we add a new shortcut -- such as ctrl+t or alt+t, sending 
a note to lake to see if that is possible. 

Opening a bug against jfrancis to ensure we support \t in the editor
Assignee: beppe → rods
Ctrl+t is possible for Browser and for Composer but not for Mail at the moment. 
It would be real nice to have it work the same way on all of these. But there is 
legacy with that combination for getting new mail. Ctrl+j is so much less 
intuitve but it is avaliabel on all of these so far.  If we want to use ctrl+t 
every where we need Mail buy in. ctrl+shift+t is also taken by a similar 
function in Mail.
i dont get it.  editor already supports tabs.
Status: NEW → ASSIGNED
Target Milestone: --- → M17
I don't get it either... but I am setting it to M17
this has to do with tab behavior in forms, in the browser -- not composer. 
Reassigning this to saari
Assignee: rods → saari
Status: ASSIGNED → NEW
*** Bug 18934 has been marked as a duplicate of this bug. ***
How about this?:

Action                  Effect
---------------------------------------
Move to next field      Alt-Right Arrow
Move to previous field  Alt-Left Arrow
Insert tab character    Tab

As far as I can tell, this satisfies all three requirements and should be able
to work on all three platforms (at least it should work on Windows and Linux --
Apple can use CMD-Arrow).


Stephen, not only is the Alt+Left/+Right key-binding you suggest inconsistent 
with all three major toolkits (Windows, Mac, and GTK), but it is also reserved 
for Back and Forward (see bug 39038).

I'm just watching, fascinated, as people come up with ever-more-obscure keyboard 
combinations for doing something as simple as entering a tab character. All I 
need now is some popcorn. :-)
URL: http://bugzilla.mozilla.org/enter_bug... → http://critique.net.nz/project/mozill...
I Just noticed that currently hitting tab in a TEXTAREA will place a 'tab'
character into the TEXTAREA and move you forward one widget. This is bad! AFAIK
Html text widgets aren't supposed and have never taken tab characters. I know
for a fact that this "feature" will break some CGI code I've written in the past
that takes advantage of the fact that web browsers don't send tab characters to
the server.	

This is not 100% true.  On Netscape 4.72, entering a tab in a text area will
enter a tab into the field.  It will not, however, move to the next field.  It
should do one or the other but not both.
Joseph, read the whole bug report. Mozilla (in its Netscape incarnation) has
*always* supported entry of tab characters into textareas. If your CGIs will be 
broken by Mozilla allowing tabs, they're broken already. And the duplicate 
behavior (entering a tab character *and* going to the next field) has already 
been noted.

I see that this bug is currently directed towards breaking WAI guidelines #5.8 
and #10.2, in order to provide one of the possible implementations of WAI 
guideline #7.3. I believe this is referred to as `one step forward, two steps 
back' ...
Target Milestone: M17 → Future
*** Bug 56407 has been marked as a duplicate of this bug. ***
Component: Editor → Keyboard Navigation
QA Contact: elig → sairuh
Nominating for relnoteRTM.  Is there currently any way to get to the next field?
Keywords: access, relnoteRTM
Whiteboard: relnote-user
After all that ...


*** This bug has been marked as a duplicate of 2083 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
actually I don't think this is a duplicate of #2083.  This bug might be better 
summarized as "What keybinding should allow users to enter /t in a multiline 
textfield?"

We know we can't use tab, shift-tab, and apparently ctrl-tab, meta-tab, and alt-
tab.  Does anyone know if we can use ctrl-shift-tab?  ;-)

Oops, sorry, you're right. This bug as originally reported is the exact
*opposite* of bug 2083. Bug 2083 is complaining that Tab doesn't take you to the 
next form element, whereas this bug is complaining that it does. So currently 
this bug is either WORKSFORME or WONTFIX (depending on your point of view), while 
bug 2083 remains to be fixed.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
updating summary; I don't think we need to release note this bug for RTM

Saari--are you the right owner for this bug?
Keywords: pp, relnoteRTM
Summary: In TEXTAREA: navigate = Tab/Shift+Tab; enter tab char. = ??? → keybinding needed to enter /t (tab) in multiline textfield (textarea)
I still think that the right fix for this problem is to provide an ``escape''
from a textarea that launches your favorite text editor in a new window. That
editor of course lets you enter tabs by just using the Tab key, and also does
all the other fancy stuff you need.
See bug 13474 (or bug 38839 that I filed as a dup) for the relevant RFE. Any
reason why this is not the way to go?
Brade, I've been ignoring this bug for the time being. I was really waiting for
everyone to work out what they feel the correct thing is, I don't know.

So I'm probably not the right owner given that you've all thought about this far
more than I have. You want it?
Personally (as a Windows user), I've never wanted to use a tab in a textarea and 
I have never seen any site that would expect one.  But in the web app I'm 
developing, having the tab key move forward makes moving through the querying 
that much easier.  If I was merrily tabbing through one line text fields and 
select boxes etc I would never remember to suddenly press ctrl+tab at the 
textarea.

If the standard textarea behaviour is different on different OS's, it's probably 
fair enough to make the behaviour for Mozilla different as well.  The standard 
for windows does seem to make tab leave the textarea


I rely on [tab] entering literal-tab daily. Editing WikiWiki pages (and
email-over-CGI, for that matter) really does need literal-tab support. (WikiWiki
pages use tabs to control list indentation etc.etc.)

One suggestion I read above that perhaps hasn't received too much in the way of
discussion: what about some kind of modal interface? The suggestion that the
whole TEXTAREA receive an outline-border (and [tab] moves to next-form-field)
until, say, [enter] was pressed, at which point "edit-mode" is in effect and the
caret appears, with, say, [esc] returning you to the outline-border
"navigation-mode" is the one I was thinking of. Yes, it's modal, but don't hold
that against it :-) With suitable visual/auditory/other feedback I believe it
could be viable.

Or a keystroke to fire up an external editor...?

Either way: I *need* literal-tabs. (As do all other WikiWikiUsers.)
The following may be a good visual indication that the user is in "modal" mode
(as opposed to "navigation" mode where [tab] moves to the next field):
- a new window is created, titled "Edit Textarea", containing only the textarea,
  located at the same position where the original textarea appears in the page
- the textarea on the page itself is disabled for the time the "Edit Textarea"
  window is up (to avoid confusion in case the user moves on of the windows and
  the "original" textarea becomes visible)

This approach would integrate well with the "keystroke to launch an external
editor" solution: The built-in "Edit Textarea" window would be just one of the
available "external" editors. (See bug 13474 and bug 38839 for the RFE.)
Why has this bug still not been fixed since it was opened well over a year ago
and mozilla 0.9 *STILL* can't enter tab characters in <textarea>s ?

Can someone up the priority of this so it actually gets fixed instead of being a
very pretty, very academic, and completely pointless log of user interface
guidelines resulting in a poor UI?
The reason this bug has not been fixed yet is that there has been no decision on 
what keybinding should be used to enter a tab character.  When we have consensus, 
this bug will get fixed.

How about accel-shift-t?

I just went back and reread this entire bug. Wow, we really tried everything, didn't we? :)

I think we've already decided that tab should always tab to the next field, whether in a single or multiline textfield. So, the discussion (as I see it) has moved to: what UI method would we like to implement to insert a real \t?

There's a few options I can think of.

1) floating windoid with button to insert \t. Bad because it takes up screen real estate, wastes time because it must be displayed/hidden by the user when they need it.

2) A button along the edge of the browser window that would add a \t to any field. Better, but not perfect since a rather large mouse move has to be made. This would suck if you had to add lots of them.

3) A button along the edge of the browser that  would turn on "edit" mode, which would change tabbing behavior in multiline text areas. The user would simply click the button again to go back to the normal tab=move to the next field behavior. I like this one the best, because it really offers the best of both worlds.

4) A UI element along the edge of the TEXTEDIT itself. This element would only show up on multiline text areas, and if it was small I think there'd be little worry of accidentally hitting it. Better, since there would be a small mouse movement to insert a \t, but not perfect.

5) Some keypress that could be standardized on all platforms. It doesn't look like there is one. Maybe ctrl-t instead of ctrl-tab? Not very intuitive, but we could do something like this if we listed it as a menu item too. Then the user has some obvious way of discovery.

6) A menu item. Once again, lots of mouse/button movement just to add a keyboard character.

7) Leave it to the web designer. This is bad because then it'll be different on every page you visit.

8) Have an option to fire up an entire new editing window. This seems like a "big" answer to what should be a small problem. Also makes the page very modal, in that editing the text area must be completed before you're allowed to change other UI widgets in the page containing the TEXTEDIT.

One interesting thing to consider: since IE can't add \t to multiline text fields, a good implementation of this feature could actually get Moz used by some set of the population who require this feature.

If we choose any of the above, then we can safely change this bug to an RFE. However, it's an RFE that needs to be implemented before 1.0 ships, because once we've set a precedent that Moz can't insert \t in text fields, web page designers will be forced to work around this problem, and we probably won't get another chance to implement this and know that designers will depend on it.

- Adam
Your list of solutions looks good, Adam; however, I'd just like to point out
that your solution 8 has a "strong" and a "weak" form - for the strong form, of
course, you would fire up a new edit window, but for the weak form you needn't
fire up a completely new window - you could simply (ahem) have a (dare I say
it?) vi-like modal interface to the textarea, where something like [enter] makes
the caret appear, and [esc] or click-outside-the-textarea returns you to
"navigation mode"... so it's not necessarily as modal as you imply it might be :-)

Of course, "somewhat modal" is very like "slightly pregnant", so your point
might well hold despite my personal preference for option 8 :-)
Lake said: 
> Ctrl+t is possible for Browser and for Composer but not for Mail at the 
> moment. 

Where exactly in Mail do we need to enter tab characters in multiline text 
fields in this way? This is a browser-only forms issue, surely. Or are you 
talking about HTML mail?

Regardless, the 99% case here is web forms in Navigator, for which ^T is free, 
and reasonably obvious. Let's implement that, on the basis that 99% of a loaf is 
better than no bread.

Gerv
Mail has this big edit box where people type messages.  Editor has this big box 
where people type in web pages (or javascript, or text files).

Aaron: I think it's fair for us to reserve accel-t for inserting a tab.  Let's 
figure out what to relocate editor's current accel-t to.
Inserting a "tab" doesn't really make much sense in an html document.

I think the only other place where users *might* want to insert a tab character 
is in plaintext mail compose.  I'm tempted to make that a separate bug...

Please oh please don't make Accel+T insert a Tab.
Accel+Shift+T maybe, or Ctrl+Alt+Tab, which is what's listed for this feature in 
www.mozilla.org/projects/ui/accessibility/mozkeylist.html


> Inserting a "tab" doesn't really make much sense in an html document.

Maybe not, but entering formatted text in a textarea makes sense. And in the
Linux version of Netscape 4.x you can press tab to achive this using tab.

	foo	bar	baz	blabla	
	blubb	this	is	just	
	a 	table	of 	words

I won't ever use Ctrl-t or some other cryptic key for this as long as it's not a
keybinding used by other popular text editors.

That's why my preference is option 8): Switch a text-area to edit mode with
Ctrl-Esc or something, and pop up a window that contains only the textarea, as a
visual indication for this edit mode. It's a clean solution that points into the
right direction for future development: Support for external editors. Of course,
a simple implementation does not need have this "big" feature yet.
Tony,

>vi-like modal interface to the
>textarea, where something like
>[enter] makes
>the caret appear, and [esc] or click
>outside-the-textarea returns you to
>"navigation mode"

This won't work, because it has already been agreed upon that tab always moves
from field to field. The powers that be don't want to force the user to "click
outside the TEXTEDIT" to go back to edit mode; they want to know that any time a
user hits tab, they always move, whatever kind of field they happen to be in.

I'm also not much for option 8. Good UI design calls for the least modality
possible. Sticking a big text box in someone's face, and forcing them to deal
with it to continue editing the form, is really bad.

This is why I like option 3. There is already a precedent for this kind of
behavior: look at the online/offline icon at the edge of the browser window. A
user may need to access this icon to go online to view web pages, if someone
accidentally clicked it previously. In the same vein, a toggle button at the
border of the browser window could toggle "Edit Mode" on or off, and there could
be a menu item in the Edit menu as well. This button/menu item would change the
behavior when the caret is in a TEXTEDIT: the tab key always moves to the next
field when Edit mode is off. When Edit mode is on, tab always moves to the next
field EXCEPT in multiline text areas, in which case tabs are inserted. Clicking
the button again turns off edit mode, and takes you back to default behavior.

IMO, this is the best solution. It doesn't require the user to learn a new
keypress, and it still allows for desired behavior in either circumstance.

My alternative to this is option 5. If we can agree on a xp keypress, this would
probably be less time consuming to implement, and would likely give us a method
of inserting a \t in the 1.0 timeframe. There's also nothing barring us from
option 3 in the future.

- Adam
Adam: I agree with you, option three is not so bad. I hadn't thought about it
properly before. (It's kind of "modal" in a less vi-like way, of course :-) ).
It would be especially nice if Moz remembered your setting for this button
across sessions... somehow. <shrug>

Option three means you have a clear visual indicator that you are in "netscape 4
tabbing" mode, ie. [tab] means insert-literal-tab. That's cool with me, since it
offers the possibility of *having* a "netscape 4 tabbing" mode, which up until
now I thought had been ruled out (because of overloading [tab]).

And yes, option 5 in the meantime is also a good idea. As Gervase says, "99% of
a loaf..."
> 8) Have an option to fire up an entire new editing window. This seems like a 
> "big" answer to what should be a small problem. 

Isn't it an even "bigger" answer to have a new, permanently visible UI element
for this? Isn't this as bad as a pref?

Is inserting literal tabs really the _only_ functionality you are missing from
the built-in editor for textareas? What if a textarea is too small for editing
long texts? What about loading a local file, and assembling a longer text using
parts from other texts? Will these (and more) be implemented in the future,
maybe with an additional UI element for every new function? Or are you simply
drawing the line somewhere and say: the builtin-editor is good quick solution,
but when a user really wants to edit a longer text, she should use her favourite
text editor that is much better at this anyway?
If it's the latter, then mozilla needs to support usage of external editors for
textareas anyway. And the tab-insertion problem is only one of the small things
fixed by it.
I prefer use of an external editor as well.
I think there are lots of other times, besides inserting tabs, that users may 
want a different editor.
For example, they might want to fire up a WYIWYG HTML editor when posting a 
comment to a forum.
I think the external editor comments miss the point that people don't
necessarily want to have to go to an external editor *just* to be able to do
what they've been happily doing for ages in Netscape.

Having an option to use an external editor would be neat but is overkill if you
are forced to use an external editor to enter tabs.

Just find a key for it *or* at least let the user decide (as a preference or by
loading key bindings etc.etc.) that he/she wants key foo to insert a tab in a
textarea.  This way you please everyone (yes it is really possible!) because
they can change it themselves.

This is possible right?
Having an option to launch an "external" editor for a textarea does not
necessarily mean that there can't be other means to enter tabs in a textarea.
If a special key-combo for entering tabs is there in the "internal" editor,
people can use it, although I doubt that it would help much.

My assumption is that in a typical scenario you'll almost never want to enter
only a single tab into a textarea. Instead, let's say you'll typically enter
several tabs in the same text, maybe five or more.

Let's assume for now that Ctrl-Alt-Tab is the special key-combo for tabs. People
who use this would this would type:
	some text 
	Ctrl-Alt-Tab 
	some text 
	Ctrl-Alt-Tab 
	some text 
	Ctrl-Alt-Tab
	some text
	Ctrl-Alt-Tab
	some text	
	Ctrl-Alt-Tab
	some text
This is certainly possible, though not too convenient IMO. My point is that when
you are editing a longer text, you are essentially switching to a different task
than filling out a form in a web page. Your main context changes. You aren't
focused on the web site any more, but on composing your text. When you are
finished, then you continue to interact with the web page. (Of course it would
be nice and useful to be able to scroll the page while you are in "edit mode"
for a textarea, but I think that's a separate issue outside the scope of this
bug.)
Let's now assume we have support for external editors, and a "builtin"
substitute for external editors (e.g. in situations where mozilla is the only
app available on the system, or if the user has explicitly chosen to use that).
What you would do then is
	Ctrl-Esc (to launch an additional window for "edit mode")
	some text
	Tab
	some text
	Tab
	some text
	Tab
	some text
	Tab
	some text
	Tab
	some text
	Ctrl-Return (or some other key combo to copy the text to the original 
                     textarea and close the window)
I'd find this more convenient, definitely. Now I don't mind if you have that
cryptic key combo for tabs in the default mode, like Ctrl-Alt-Tab or whatever.
This can happily live together with the "external editor" feature. Just accept
that a cryptic key combo is not a solution for editing long texts. As a
short-term solution, maybe even for 0.9.1, a cryptic key combo is probably a
good thing. Just don't claim that this is a complete solution to the Tab
problem.

About the other alternative: Have the user configure their keybindings. This
approach has its own advantages and disadvantages. But even then I can't see a
reason why the user has to configure that Tab really means Tab, so I wouldn't
consider that a complete solution either.
It _may_ make sense to have a global configuration option for keybindings:
[x] Emulate IE
[ ] Emulate Netscape 4.x on Windows
[ ] Emulate Netscape 4.x on Linux
[ ] ... more if necessary
[ ] Use Mozilla's own new keybindings

But I'm not sure if this is implementable, since it's pretty much the opposite
approach of the current attempt to find a single set of keybindings for
everyone.
A while back Adam Masri wrote:

> 5) Some keypress that could be standardized on all platforms. It doesn't look
> like there is one. Maybe ctrl-t instead of ctrl-tab? Not very intuitive, but
> we could do something like this if we listed it as a menu item too. Then the
> user has some obvious way of discovery.

And this is virtually the solution I'm advocating except in order to keep
everyone happy I'm trying to say that you should let the user bind it to
whatever she/he wants.

That way TAB can tab between items in a form (which is useful) and whatever
keystroke the user wants to insert a tab can do so.

External editors will spawn another command presumably?
Editing in notepad, vi or emacs sounds a bit of overkill to me and personally I
think it's less convenient to have to spawn one.

But make it a preference as in "use external editor [/usr/bin/vim____v] for
textareas" if you want.


Andreas,

>My assumption is that in a typical
>scenario you'll almost never want to
>enter only a single tab into a
>textarea.

I believe your assumption is wrong. You should go back and reread this entire
bug. I believe that behavior is explicitly requested by multiple people.

Giving the user the ability to fire up an external editor is nifty, especially
if you're an emacs user. Anybody who says the ideal editor is vi, well, I've got
some swamp land in Florida I'd like you to have a look at... In any case, I'd
say the 90% case of people who would use this feature are power users who are
highly efficient at using their preferred external editor. In the Mac world (and
likely to most non-power users in the Windows world) this behavior would throw a
highly modal user environment in front of the user. IMO, most Mac users would
never make use of this feature, and would be confused by it. Power users might,
if they were editing a large document.

I would suggest that the idea of adding an external editor is an excellent RFE,
that should be logged under a separate bug. This bug explicitly discusses how to
get Mozilla to insert a \t in a TEXTEDIT using a built-in method of the Mozilla
interface.

The problem I have with Simon's idea of allowing the user to change the
keybinding mainly has to do with the UI. The power of Netscape originally was
the ability to walk up to ANY computer running Netscape 1, and do something on
the web with it, even if you didn't know that platform's UI completely. I'd like
to know that I could walk up to virtually any platform, and use the knowledge
I've learned previously. To me, that means coming up with a consistent use of
control-t, if that's our preferred keypress. This goes back to someone actually
Making A Decision (TM).

For expediency, I'd like to see control-t implemented, if it was xp. There is a
good chance that we could actually see that ship installed at launch. As long as
the ability is there in 1.0, then we can count on users being able to do this.
We can always go back and work on better methods later. Comments?

- Adam
Adam, I read the whole bug again, and I could not find a single reference to a
situation where, while editing a textarea, you'd want to enter a tab only
_once_. Given a textarea, there are two cases:
- either you don't want to have any tabs in there, then there is no problem
- or you want to insert tabs in _several_ places while editing your comment
If you can think of a case where you edit a textarea and you only need to insert
a tab _once_ for this textarea, please describe the case or give a more precise
reference. Otherwise I'll stand by my assumption and claim that "Tabs always
come in groups".

The RFE for external editor support is already logged as bug 13474 / bug 38839.
And no, I don't propose to "only" support external editors for inserting tabs.
Instead, the "default" editor could very well be a built-in editor
implementation that behaves exactly like a textarea, with the only exception of
inserting a literal tab when the tab key is pressed. This built-in editor would
pop up immediately when you request it, so you wouldn't lose much time for
inserting tabs.
 
I don't know about modality problems. Anyway. Let me try to re-summarize the
"realistic" options, given that I should not need to use the mouse for each and
every single tab over and over again (this rules out options 1, 2 and 4, and
allows option 6 (Menu Item) only in combination with option 5 (some cryptic key
binding). Option 7 (leave it to the web designer) is bad indeed.

So the remaining options are:
3) an "edit mode" with a permanently visible toggle element in the UI
5) [+6)] a key binding [and a menu item]
8) a key combo to escape into "edit mode" for the currently focused textarea
only, with a new window or some other clear visual indication of edit mode

Plus, the other options ("make it a pref"):
P1) make the behaviour of Tab a pref
P2) make the complete set of keybindings a pref (e.g. "Nav for Linux" mode)
Pgeneric) make all keybindings changable individually

Nearly none of these options excludes the others. I think option 3) would be
good as well. But isn't it just a boolean pref (option P1) together with a
permanently visible UI toggle?
Andreas,

	Adam, I read the whole bug again,
	and I could not find a single
	reference to a situation where, while
	editing a textarea, you'd want to
	enter a tab only _once_.

There, you just got one. Indents. (For those wondering, I typed this into an
external wp (TextEdit on MacOS X) and pasted it into the TEXTEDIT in this
submission form. If Andreas' comment was one line, then I'd have only needed a
single tab.

Seriously, let's see what you and I do agree on. Do you agree that having some
method of inserting a \t would be useful in Mozilla 1.0? And do you agree that
in order for that to occur, we need to agree on the most expeditious method of
implementing that feature?

- Adam
I am typing this on Windows Netscape 4.7 and I am surpised that I can't enter a 
tab in a text edit.  I am usually on Solaris or Linux when I do this type of 
editting.

I think that Andreas' idea for a global keybinding option is a good one.  This 
would allow the typical user to quickly configure the browser to work how they 
want it to work.  However, I think it should be customizable beyond this so that 
I could do, for example, default to Mozilla keybindings but change <TAB> so that 
it will enter a tab only in a multi-line text field and tab to the next field in 
every other case.

I don't like any ideas that require me to click on some widget with a mouse to 
insert a tab because that requires me to take my hands of the keyboard.

An aside:  What happens if you cut and paste some text that includes tabs?  Is 
it the same on every platform?

> If Andreas' comment was one line, then I'd have only needed a single tab.

True. However it's quite unlikely that you quote only a single line using
indentation. Usually there are more, in your example there are five.

> some method of inserting a \t would be useful in Mozilla 1.0? 

Yes, definitely. But on the other hand I think the keybinding for inserting a \t
should be the "Tab" key and nothing else, at least for the "real" solution.
Anything else would be odd, and if I were forced to choose, I would rather
provide alternative keybindings for "going to the next item" and "going to the
previous item" (e.g. some Modifier-CursorUp/CursorDown, if they weren't use by
the system itself) than to use a cryptic keybinding for inserting a \t.
Of course, this is my subjective view, and not representing the majority of all
users, but the fact that the long discussion in this bug still has not reached
consensus on a suitable substitute key binding may indicate that there isn't any
good one at all.

I appreciate the attempt to find a unique, cross-platform set of keybindings,
but in this case I really prefer the Linux (or non-Windows?) solution, and I
expect at least some non-visually-impaired Nav4/Linux users will agree.

> we need to agree on the most expeditious method of implementing that feature?

Not necessarily. If there is to be _a_ solution in the next Netscape 6.x
release, then we indeed need to agree on something quickly. I don't think it is
realistic to have the "real" solution in the next Netscape release, especially
it's clear that the "escape into edit mode" solution cannot be done in time. So
a cryptic key binding may be good as a short-term fix, but for mozilla 1.0 or
mozilla 1.1 or something like that, I'd really like to see a better solution.
As long as nobody claims the problem "FIXED" before I can use the "Tab" key to
enter tabs like I could in Nav4, I don't really care what the actual key combo
is. (Of course it may make sense to use a new bug for the "real" solution, as
this one has become quite quite a long discussion log.)


Well, another month has passed, and we still can't make up our minds on this issue.

Andreas,

> >some method of inserting a \t would be useful in Mozilla 1.0? 

>Yes, definitely. But on the other hand I think the
>keybinding for inserting a \t should be the "Tab" key and
>nothing else, at least for the "real" solution.

Gee, well that's useful. Unfortunately, as has been explained again and again,
you will NEVER get that functionality. TAB has been reserved for moving between
fields.

No more discussion on this bug will yield any fruitful results. Once again, I
ask Netscape engineering to check out the following list of possible options:

1) floating windoid with button to insert \t. Bad because it takes up screen
real estate, wastes time because it must be displayed/hidden by the user when
they need it.

2) A button along the edge of the browser window that would add a \t to any
field. Better, but not perfect since a rather large mouse move has to be made.
This would suck if you had to add lots of them.

3) A button along the edge of the browser that  would turn on "edit" mode, which
would change tabbing behavior in multiline text areas. The user would simply
click the button again to go back to the normal tab=move to the next field
behavior. I like this one the best, because it really offers the best of both
worlds.

4) A UI element along the edge of the TEXTEDIT itself. This element would only
show up on multiline text areas, and if it was small I think there'd be little
worry of accidentally hitting it. Better, since there would be a small mouse
movement to insert a \t, but not perfect.

5) Some keypress that could be standardized on all platforms. It looks like
ctrl-t could be used throughout. I believe someone said it is currently used in
Mail?

6) A menu item. Once again, lots of mouse/button movement just to add a keyboard
character.

7) Leave it to the web designer. This is bad because then it'll be different on
every page you visit.

8) Have an option to fire up an entire new editing window. This seems like a
"big" answer to what should be a small problem. Also makes the page very modal,
in that editing the text area must be completed before you're allowed to change
other UI widgets in the page containing the TEXTEDIT.

For expediency, I ask you to seriously consider option 5. We could have this
feature in place before 1.0 ships. If the keybinding was modifiable, that would
appease most of the dissenters here.

- Adam
> you will NEVER get that functionality. 

short-term, no. long-term, I'm pretty sure that I'll get it. The "alternate
editor" approach simply has too many benefits.

I don't think I have ever opposed to option 5) [or 3)] as a short-term temporary
fix. I just strongly oppose to considering it a complete, real fix.
If someone here (Andreas Franke? others?) finds it desirable to have an editor to 
edit textareas, a separate bug should be filed on that issue.  I would consider 
this bug fixed if there is *any* mechanism for a user to input a tab character.

If accel-T is available in the browser, we should grab it for inserting tabs (if 
Aaron L agrees to put it in his spec).  If you can't enter a tab in mail compose 
because that keybinding doesn't work there, is that really a problem or not?

>If accel-T is available in the browser, we
>should grab it for inserting tabs (if 
>Aaron L agrees to put it in his spec).

Accel? Do you mean control? There is no "accel" key on a Mac... We have command
(usually reserved for activating menu items), option (usually reserved [by
itself] for entering modified characters, such as a tilde-n, umlats, etc), and
control.

>If you can't enter a tab in mail compose 
>because that keybinding doesn't work
>there, is that really a problem or not?

I would think that while we're doing this, the same key should do the same thing
across the interface (mail & news, composer, and browser). I don't think we want
the user to remember multiple methods of doing the same thing across the
interface. According to Lake (earlier in this bug), ctrl-t is currently used on
some platforms to get mail. Is there any chance of changing this?

- Adam
accel is the shorthand used to describe the modifier key used for commands 
(Command on Macintosh; Control on Windows; Alt or Control on Linux depending on 
your preference settings)

I agree about the desire to unify keybindings across all the components and all 
the OS.  I'm simply asking if it can be good enough for just navigator or not.  
If the answer is no, then this bug can (probably will?) stay Future.  :-/
I don't know about the likelihood of changing the keybinding in Mail; you may 
need to e-mail jglick@netscape.com and ask her.

personally i think we can grab accel-t. there's no need to get mail while 
you're composing a message <period>.  If someone wants to get mail, they can 
probably click on the mailbox, or switch to another window and use accel-t.

--the arguement below can be ignored--
Actually, for mail assuming we aren't too demanding, i'd be willing to accept 
<tab> for inserting tabs. and leave it inconsistent w/ the rest of the suite.

Here's the argument for tab: you can use shift tab to get to any field you 
want.  There are no fields after the mail compose field. There is very little 
reason you would go from the edit field to the address field. It's 4xp.  mpt 
has argued that the components of our suite should be treated as seperate 
applications.  Hopefully on macos the mail windows aren't expected to behave 
like browser windows (which would mean having browser menus - like bookmarks).  
Browsing is inherently different from writing email.  In browsing you need to 
navigate up and down a page, even selecting random objects in between.  In 
composing email you only need to write the email. In the rare event that you 
need to change the first field of the window, you would probably use accel-l 
(assuming we are consistent w/ browser - yes that goes against the vein of my 
argument but ...), in all other events you would just use shift-tab.
--

And now back to flaming everyone :) <rant>
aaron provided his annoying url 
http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html
and said that ctrl-t (accel-t whatever) was not available.

We have talked about escapes and modality, both here and in other bugs.

So here are two useless suggestions which everyone will ignore (that's an 
order?).

1. scrolllock toggles tab behavior for edit boxes.
This probably makes some sense for a few reasons, but i'm not going to try to 
persuade anyone.

Here's how it would work.
I tab into an edit field, and press the scroll lock key.
this	enables	me	to	enter	tabs	at	random.
	This	makes	me	very	happy.	When	I	finish	
entering	my	complete	message	I	press	the	
scroll-lock	key.	Now a tab will take me out of the edit field.

2. Escape key to exit manual input mode.
Current uses of escape: stops page load. stops image load. stops animation.
None of those uses will be common while a user is entering a form.

Here's how it would work.
I tab into an edit field.	Tab	inserts	tabs	:-)	I'm	happy.
	When I need to leave the field, I press <escape> because there's some 
logic to pressing <escape>. (I'm not going to spend my time thoroughly 
explaining it but you're editing and you want to _escape_.) Mozilla now puts a 
highlight or something around the textarea and shows that i can't enter text 
anymore (this is probably done by a gray select mask or something), if I need 
to enter more text, I press <enter> and the textarea becomes usable again.  
While the text area is not usable, if I press tab, mozilla moves focus to the 
next element.

This use of escape/enter pairs is described by me in some other bug, but it was 
a long time ago and aaron wasn't interested in it. That's ok because aaron 
doesn't care about this bug except as an obstructionist.
</rant>

Conclusions:
when people want to enter tabs/formatted text they want to enter _lots_ of tabs 
and formatted text. this means that ctrl-t while nice in limited usage will 
suck for the real users.  It's not impossible, because I was using ctrl-v to 
insert tabs while I used this edit field (ctrl-v doesn't usually insert tabs, i 
had to cut a tab from nc4composer into my clipboard ...), but it isn't 
comfortable.  The proposals I've offered in my rant only require two 
keystrokes.  and result in a need for only a single key while entering tab 
formatted text.  This is arguably just as good as any other proposal made here.

From aaron's rather annoying page:
Escape key:
Browser		Composer	Mail panes	Widget Behavior
Stop loading	Nothing 	Nothing 	Cancel dialog
Stop animation

Ah, that would have been easier w/ a tab key.

Scrolllock doesn't appear on the page aaron mentioned.

from another page, 
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
No Ctrl+Alt combinations. Good I'm glad we settled that one.

My 2 mac keyboards (5 years old?) have f14 scroll lock.
Macintosh Keyboard Differences

Not all Macintosh keyboards are the same. For example, older macs may not have 
any function keys at all, newer Macs have F1-F12, very few have F13-F15 
(F13-F15 are usually labelled Print Screen, Break etc on PCs). When function 
keys are present, Mac OS allow users to define their actions (macros). For 
these reasons we want to avoid the only key binding for a feature being on a 
function key. If the feature is important or common, it must have an 
alternative means of activation.

^This basically means my scrolllock proposal won't work too well on macos.  one 
approach would be to use ctrl-t as an alternative binding for the scrolllock 
key.  My mac keyboard has a scrolllock indicator and I think most new mac 
keyboards do too.

It's true that imac keyboards have less keys, but I think that ctrl-t to 
activate scrolllock _if_ there is no scroll lock key on the keyboard (i can't 
remember) would be tolerable.

Oh, as always if you ever want to use an external editor, it's really easy. run 
it, type whatever in the world you want, use whatever means your OS provides to 
copy, and then paste it into your edit box.  This is probably a good thing to 
do in general, especially w/ mozilla (or communicator) since they might crash 
and eat your lovely composition.  There should be nothing stopping this.  I'm 
tempted to file a bug just to relnote this wonderful piece of advice.
>I agree about the desire to unify keybindings
>across all the components and all 
>the OS.  I'm simply asking if it can be good
>enough for just navigator or not.

Let's go for it. I'd rather have it in with 1.0, and make it better or change
its method of activation later, than not to have it at all.

All I ask is that a menu item be listed, with the accel-t command listed in the
menu. (Perhaps in Edit.) That way, the user has an obvious method of discovery.

If we do this, then this bug can finally be closed (thank goodness), and the
other requested behaviors can be listed as new RFE bugs for the future.

- Adam
> If someone here finds it desirable to have an editor to edit textareas, a 
> separate bug should be filed on that issue.

Maybe I repeat myself, but the RFE for external editor support is already logged
as bug 13474 / bug 38839.

timeless: I like the scroll-lock idea. See also my comments from 2000-05-04
17:42 and 2000-05-04 21:51:
> Actually, KDE uses the "Scroll Lock" key to swich on/off this predefined
> behaviour of Ctrl-Tab and Alt-Tab (and maybe other keys).
[...]
> The user should always know whether this ``edit mode'' is active
> or not, so maybe one could use the "Scroll Lock" key for this (there is an LED
> associated with it). 
> As far as I can see, this would not violate the decision that has been made.
> What would be the problems with this approach? Are there any major platforms
> that do not have this key? Are there any problems with the detection of the
> current state of this key? Would this cause any major usability problems?

I don't remember if there were any arguments against this...

Andreas,

	I don't remember if there were any arguments against this...

The only argument is one of expediency, as has already been pointed out.

The fact of the matter is, I too want a way of doing some kind of field lock so
that multiple tabs could be entered. But this is 1.0. It doesn't have to be
perfect, it just has to work.

Please file an RFE for your other requested behaviors. If we can get the single
fastest to implement method complete, then we can close this bug (finally).

- Adam
Scroll lock might be used to activate panning (the equivalent of a mouse wheel
click).  See bug 63712.
I like the scroll lock idea.  If scroll lock is on, then it works the old way 
(tabs advance in every field except for TEXTAREA).  If scroll lock is off it 
works the new, Mozilla, way (tabs advance in every field).
I can imagine a user pressing Tab, and not being able to navigate wondering what
was up. Turns out scroll lock is on by default on their system, or maybe they
hit it by accident. Trouble is, there's nothing to tell them why tab isn't
working the way it usually does.
You know, if you were using arrows, Alt-Arrow for example, instead of tab to 
navigate then this whole tab discussion could be moot.
Mail is using Accel+T for Get New Mail and Accel+Shift+T for Get All New Mail 
(multiple accounts).  Getting new mail is a common action so it should 
have a simple accelerator. I don't believe there are any single letter+accel 
combinations not being used currently (to which it could be switched).

Sorry if this was already mentioned, but is accel+Tab available for this? Or 
Accel+Shift+T, or Ctrl+Alt+Tab, as mentioned by Aaron?
Accel-T?  What are Accel-M or Accel-G being used for?  Accel-T doesn't seem
intuitive to me.
jglick: i still don't see why anyone is likely to check their mail from a 
compose window. accel-2;accel-t should always work.
>jglick: i still don't see why anyone is likely to check their mail from a 
>compose window. accel-2;accel-t should always work.

I think of Mail Compose not as a separate entity, but as a sub window, a method 
to do a particular task, associated with the Mail application as a whole. For 
the sake of consistency, I think its good when the whole application uses the 
same accelerators consistency.  I agree it may be uncommon for someone to want 
to retrieve mail while composing an email, but I think its potentially confusing 
that an accelerator do one thing when composing an email and another thing when 
not composing an email, all the while, still within the mail application.  Just 
my opinion.
Timeless's Scroll Lock idea would probably work very well for the small segment 
of the population who would be comfortable using the vi text editor. For 
everyone else, even those who had no need to enter tabs in the first place, it 
would be rather disastrous. (`Damn, Mozilla's frozen up on me *again*! And I'd 
nearly finished writing that message, too. I'm getting sick of this ...')
I've used Netscape/Linux for a long time, and I'd like to start using
Mozilla/Linux, but this is a critical issue holding me back. I use Wikis for
collaboration and Wikis usually require tabs for formating. It seems crazy to me
that Mozilla is ignoring this whole class of applications just so it can mimic
another web browsers behavior (from the comments above, I am guessing that
IE/Windows uses tab to jump to the next widget). By making the tab key special
instead of entering at tab character Mozilla is making an arbitrary restriction
on what I can type in an edit box. To make things worse, I can't even cut and
paste a tab into the edit box. Most applications make keybinding configurable.
Doing so here would solve the problem since there will obviously be no agreement
on the issue. As more applications get web interfaces, this problem will get
worse. The edit box needs to be a 'real editor' -- with the tab key -- to
support wikis and other applications.
I don't much care what happens in textarea boxes in the browser.  But I need to
get a tab when I hit the tab key in the mail composer.  Whatever you do, don't
change that.
That's just plaintext mail composer, of course, correct?
This bug is a major usability problem for me when "editing a patch as comment"
in mozilla with the new attachment tracker in bugzilla. I often hit the tab key
and have to find that my cursor is gone (because it has gone to the next item,
the "Undo Edit As Comment" button).
I think I will have to fire up a sane editor (emacs) manually, cut & paste the
content from the textarea into the editor, and cut & past it back when I'm done. 

Congratulations.

Re: usability concerns.

I think timeless is correct in his suggestion for access keys (either using 
scroll lock or defaulting to edit mode, and using escape to exit from this). 
However a number of people have pointed out that the modal nature of the scroll 
lock choice (1). Similarly, choice (2) is not entirely intuitive in its choice 
of escape as the exit key.

Could I suggest that since this is a modal choice, the edit box essentially 
reflect this modal decision through a user interface change?

The most intuitive user interface change would be to display tab bar above the 
multi-line edit box, with a close button at the far right hand side (ie top-
right hand corner of the multi-line edit box) when in the multi-line edit field 
in tab-stop mode.

This would look like the following:

=======v=======v=======v=======v=======v=======v=======v=======v=======v==[x]
|The text I am currently editting...                                        |
|      And     I       can     see     the     tab     stops.               |
|                                                                           |
|                                                                           |
-----------------------------------------------------------------------------

This addresses the problem with novice users not being able to exit out of the 
tab editting mode. (They can click the close button, in addition to using 
Escape).

Furthermore it makes it clear when you have scroll lock depressed (You can see 
the toolbar).

As for defaults, I would suggest the following:

1.          Default to edit mode for the first scroll-able multi-line edit box 
only.
2.          Upon exitting the edit box by pressing escape, clicking the close 
button or clicking elsewhere in the page, display a dialog with the following 
text:


---
Mozilla provides Quick Edit to assist composition in multi-line edit boxes. 
When using Quick Edit, the tab key inserts a tab and page up/page down scrolls 
the multi-line edit box. When not using Quick Edit, the tab key tabs to the 
next form element, and page up/page down scrolls the page.

You can invoke the Quick Edit feature in any multi-line edit box by pressing 
the Scroll Lock key.

Start the Quick Edit feature?
(*) Always
( ) In scrollable multi-line edit boxes
( ) Only with the Scroll Lock key

[ ] Use an external editor instead   [Choose]

[x] Do not display this dialog box again
---

3.	Use the scroll lock key to invoke/remove the tool bar (Quick Edit), and 
also affect page-up/page-down semantics elsewhere in the page (bug 27771).


This way we turn a bug into a feature :)

Just my tuppence worth...please ignore if it's a stupid idea...but
can't we make the decision to have the textarea (or textfield for that matter)
include tabs upto the designer of the form? Seems to me something like :

<input type=text tab=yes>

or whatever is the correct html...

Max.
*** Bug 109763 has been marked as a duplicate of this bug. ***
I was surprised to see this issue still not resolved.  Using the user
documentation as a guide, the shortcut keys to move between form elements are
specified here:
      http://www.mozilla.org/docs/end-user/moz_shortcuts.html#forms

According to this, to move between form items is TAB and SHIFT+TAB.  Using
CTRL-TAB to insert a tab (/t) makes logical sense.  Similar key bindings exist
to move within a textarea using CTRL-HOME and CTRL-END.

This document is quite recent (May 2002) and there are parallels for Mac users
to replace the CTRL key with the COMMAND key.
Control-tab is already being used; it is not available for this purpose.
I understand that CTRL-TAB is being used to put focus in the location bar. 
However you can still access it using the TAB/Shift-TAB keys.  There is no
method to insert a tab.  Also, for usability one would expect to use the TAB key
(in some form) to insert a tab in a textarea.  Is it impossible (outside the
scope) to remove the current key binding and implement CTRL-TAB as a method to
insert a tab (/t)?
*** Bug 215512 has been marked as a duplicate of this bug. ***
This is a big problem for me, as I need to edit some wikis
a work arround is to copy a tab and paste it...  but I first have to find a tab
to copy! (normally easy on wiki's with tabs.. but creating a new page sucks
I see there is a patch... but I've never need instructions on how to actually
implement a patch!

anyway, as I recall this is standard behavior on IE 5 and 6  and it used to work
on mozilla...

I don't care if there is a "control-tab" or "shift-tab" or whatnot... I tried
them all and no tab appeard.

another option is to have an insert menu... tools-->insert tab  or something
like that


Any idea when this bug will be closed? 
In Mozilla 1.7rc1 if I hit <Ctrl>+<Alt>+<Tab> nothing happen. This combination
of keys can be used to insert TABs in a textarea.
This is quite a problem if you have to edit a Wiki... can't we simply have TAB
acting as a normal \t in textareas, while it moves focus in other widgets?

This bug seems to have been opened for quite a lot of time... I asked for the
1.8a4+aviary1.0 blocking flags since I feel this is an important bug for
accessibility. 

Feel free to deny them if it's not so important after all, but I guess this
should soon be fixed anyway: Wikis and forums are more and more used on the Web.

For example, in PhpBB/anyForum, if you use the monospace/code tag, you probably
would like to use tabulations.

I know there are some comments that state that "this bug will never be fixed,
just open another text editor and cut&paste", but that was 2001 and things are
different now. So please consider fixing it.

All the keybindings with TAB involved are used by my wm (KDE), so i believe the
easy way to do this is to let TAB = \t in textareas.
Flags: blocking1.8a4?
Flags: blocking-aviary1.0?
Flags: blocking1.8a4? → blocking1.8a4-
would need to have a working patch for this to be considered for aviary 1.0... 
aaron, any ideas for a better owner for this bug?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
I'll take it, but I don't know when I'll get to it.
Assignee: saari → aaronleventhal
Status: REOPENED → NEW
QA Contact: bugzilla
I wrote a simple Firefox extension for inserting tab characters in textarea fields.
You can check it out at http://tabinta.mozdev.org/

Balint
Thanks Balint... now when will it be incorporated into firefox proper?  My wiki editing has been suffering.. (I kinda would have switched over to konqueror.. except it doesn't have web developer)


Or.. Is this fixed with an about:config ?  eitherway, we need to be able to enter tabs!
We need a final UI decision on this bug from Mike Beltzner.
Summary: keybinding needed to enter /t (tab) in multiline textfield (textarea) → keybinding needed to enter \t (tab) in multiline textfield (textarea)
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
QA Contact: keyboard.navigation
Blocks: 509088
Component: Keyboard: Navigation → User events and focus handling
Severity: normal → S3
Severity: S3 → --
Type: defect → enhancement
Priority: P3 → --

In HTMLEditor, we have a Tab key handler which is enabled if nsIEditor::eEditorAllowInteraction flag is set to the editor. So, technically, this can be fixed easy. However, once it's enabled, Tab key navigation is disabled which is a really serious issue and the other browsers do not have a way to insert CHARACTER TABULATIONs without paste. So, making it available even with a modifier could cause a web-compat issue. There is another potential issue. A lot of web apps must not assume that CHARACTER TABULATIONs may be inserted into the <textarea>. So, such data might causes unexpected rendering result when users request to show the data.

Severity: -- → S4
Component: DOM: UI Events & Focus Handling → DOM: Editor
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: