Build ID: 2000080108 Shift+tab is broken in <textarea>'s. Instead of moving focus to the widget/element before the <textarea>, nothing happens.

must fix for beta3. Combined with the recent regression of bug 2083, this makes navigating out of <textarea>'s with the keyboard completely impossible.

Also exists on linux. changing OS to all.

Not sure if this is tabbing code or being consumed by the textarea

nsbeta3-, ->future: minor inconvenience, no time left for bugs like this.

Targeting Mozilla 1.0

nominating beta1 for accessibility reasons.

Taking.

If we decide to go the accessibility route in bug 2083, I think we can just remove HTMLEditor's tab handling completely. simon, sr?

r=timeless

Excellent, thanks for taking this! Yes, let shift-tab *and* tab go in and out of text fields just like they do in IE. So you probably want to kill the editor handling of tab for the non-shift case too. I know this is a holy war issue, but IE works this way and we need to make the browser keyboard accessable, and this is the standard way to do that for all the other widgets. Those reasons are good enough for me.

Shouldn't this wait for the resolution of bug 66285 (the spec for what tab should actually do)?

when making these changes, please keep in mind the navigation for tables, currently the use of the tab key moves the selection forward from cell to cell, using the shift+tab moves the selection backwards from cell to cell

The patch breaks table navigation (backwards)in Composer and causes the caret to disappear when doing a shift-tab in text. I'll attatch an updated version of blake's patch that prevents the problem, but I still think there are problems with choosing select-tab for passing on focus ... for starters it will only pass focus backwards to the previous form widget, there is no way to pass focus forwards with this patch.

Bah ... forgot to Cc myself.

r=brade Simon--please test and add your sr=

Simon, sr?

sr=sfraser

Checked in.

okay I see it working, however, the focus is going upward instead of downward. is that by design ?

Shift-tab focuses the first focusable previous widget, and tab focuses the first focusable next widget (so yes).

verified in 2/22 build.