Click on a multiline text area. Type a tab character. Focus should move to another form element. Instead a tab is entered into the text area. Build stats: ---------------------------------------------------- Unix and Windows builds from 12-29-98. Linux Red Hat 5.2 egcs-2.90.29 980515 (egcs-1.0.3 release) gtk+-1.1.9 ramiro's nspr rpm with pthreads ../mozilla/configure --enable-debug --with-pthreads 16-bit display

Since this widget is only a place-holder until Ender arrives, this bug may not be worth fixing. Reassigning to mcafee for triage

This is the same way that motif does it, so i would assume most people used to netscape would expect this behaviour.

This is current 4.5 behavior, not sure this is a problem.

Inserting Milestone info.

Setting all current Open/Normal to M4.

Text. Either ender or NGlayout.

This sounds like a Gecko bug

I don't know what the behavior is on Linux, but it is wrong on Win32. It should be tabbing to the next form control. Eric Pollmann will be addressing tabbing in a few days.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Tabbing issue for ya'. (Possible bug?)

On Windows this stems from bug 3546. Cancelling the keydown doesn't prevent the character from being typed. We need to instead handle the character so we can use the tab and then cancel. Current behavior on Windows moves focus but still inserts the tab. After 3546 is fixed I can deal with Windows. I'll have to deal with Linux separately. Since the tabbing now works, its just an issue of a tab being inserted. I think this is lower priority and this is unlikely to be fixed in the next 36 hours. Moving to M5.

Not making these for M5

The remaining part of this bug, the inability to prevent tab insertion, is a dupe of 1572. *** This bug has been marked as a duplicate of 1572 ***

this sounds picky, but most of this bug is fixed, so i'm going to reopen it and mark it fixed. the rest of the issue is covered in bug 1572.

... and verified fixed.

Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.

reopening. in 2000072008 winnt, hitting tab in a textarea inserts a tab instead of moving focus to the next widget

reassign

Joe -- is this your bug? If not, please reassign

really assigning to Joe

saari, do you know where this goes? Editor handles tabs when it receives them. If it's not supposed to be receiveing them, the problem is further up the food chain. This is the kind of thing that used to go to joki, but I don't know where it goes now...

I am a joki proxy, I'll take it

should fix this for beta3...

Yeah, I'm working on a slew of tabbing changes... give me a day or two. (forward merging is a bitch)

See discussion at bug 29086 on whether this is a bug or not.

It is a bug. It makes little sense for someone who's navigating a page via the keyboard to have to suddenly switch to the mouse because he or she is stuck in a widget. It was decided that inserting a tab character is the less common action, so for that action it should be a modifier + tab.

So editor will definitely be getting first crack at the tab event, so you guys really need to ignore them.

"It was decided"? By whom? Note that it also makes little sense for a person who is typing in a text field to be scrolled elsewhere just because they hit tab, a perfectly normal character to type in a text field. Also, if we changed keymappings everywhere according to how common they were in that context, who would be able to remember them? However, Explorer and Navigator differ on this behavior, so it is contentious. In any case, this doesn't make our short list of things to worry about for N6. nsbeta3-, ->future.

Yes, there's a bug somewhere in which a decision was made to use tab for navigational purposes only, regardless of the widget.

Agreed, but I've since been told there was careful deliberation before the decision, by some group involving the editor folks. Presumably, it is in some spec, somewhere, so it is probably a real defect. Have also discovered that tabbing out of multiline fields is actually done on Nav 4.x, but only on Win32 - Mac and Linux products just add a tab...

Accessiblity bug, targeting Mozilla 0.9

*** Bug 29086 has been marked as a duplicate of this bug. ***

Copying relnoteRTM nomination from dup. Bug 29086 was also marked as 'pp', but based on how many people have commented here I will assume the bug is no longer pp. I may attempt to create a workaround for this bug and bug 54406 this weekend.

partial workaround for release notes: http://www.cs.hmc.edu/~jruderma/mozilla/override-tab.html

*** Bug 54038 has been marked as a duplicate of this bug. ***

I assume this bug also applies to XUL elements. cc'ing trudelle to make sure XUL textfields behave the same way as HTML elements.

*** Bug 53423 has been marked as a duplicate of this bug. ***

*** Bug 64010 has been marked as a duplicate of this bug. ***

Taking... It looks like the tab insertion was done intentionally. Do we really want a tab to be inserted? I think the accessibility benefits are more important. If others (and the editor team) agree, I'll attach the patch.

it was definitely done intentionally. please see the spec bug 66285 before doing anything. This bug is now blocked.

Please consider ^I or ^T for tabbing, they were mentioned in bug 66285. Any opinions?

Timeless, that's not this bug, that's bug 29086.

either this is about inserting tabs or handling tabs. please leave this bug w/ one of those two markings. For now i'll just blame you for removing the blocker marking.

I don't think this is dependent on bug 66285, and I think we have decided in bug 29086 et. al. that tab should navigate out of text fields, so let's just make it so. It should be XP too; the Mac HIG argument was obviously a red herring, since the HIG only calls for such behavior in "text-oriented applications", which is not the case here. We don't even provide any UI for tab stops, as such applications do. Blake, will you handle this, or should we give it to BRyner who has other such bugs?

I'll do it. I think I already have a patch in a bug somewhere...

And for god's sakes, this isn't dependent on 66285. I'm fixing this to make tab move to the next focusable widget, regardless of what that bug (which went from a specific request to a broad, general "spec bug" about tabbing in general) says.

*** Bug 67907 has been marked as a duplicate of this bug. ***

*** Bug 67907 has been marked as a duplicate of this bug. ***

Fix checked in.

verified in 2/26 build.