2642 - Cycling through TEXTAREAs in tabindex order messes up

Status: VERIFIED DUPLICATE of bug 36217

(Core :: Layout, defect, P4)

Description

[bkdelong]

Tabbing through these 4 TEXTAREA elements causes the curor to move over 1 tab
space through each cycle. When user tabs through to the 4th TEXTAREA element,
instead of tabbing to the navigation toolbar or beginning the cycle at the 1st
TEXTAREA element, the cursor tabs over one tab space. Very trivial but important
to navigation of large forms.

Comment 1

[leger]

Setting all current Open/Normal to M4.

Comment 2

[Paul MacQuiddy]

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

Comment 3

[Kevin McCluskey (gone)]

Steve, I'm re-assigning this to you, You can use it as a test case for the
ender-based text fields.

Comment 4

[Kathleen :Brade]

fix summary

Comment 5

[buster]

moved to M11

Comment 6

[buster]

added rod to the cc list.  Set to M14.

Comment 7

[Sean Richardson]

Observations:
1. Tabs are no longer being inserted inside the <textarea> edit fields.
2. Tabbing does nothing until the user clicks on the page (anywhere)
   to give it focus (this is likely bug 12280).
3. * Once 2 is done, tabbing moves from <textarea> to <textarea> in TABINDEX
   order, *but the order is wrong*: 1,2,3,4, 2,1,2,3,4, 2,1,2,3,4....
4. Typing after tabbing to a <textarea> adds text wherever the insertion point
   was last left in that <textarea>; another tab moves on, as expected.
5. The page scrolls as necessary to bring the <textarea> with the next
   TABINDEX into view (subject to point 3).

The reported bug - inserting tabs - no longer seems to be happening on WinNT
at least, but the fact that inconsistency happens at the same point,
when beginning the tabindex cycle again, likely means that the same
problem is showing a different way now.

(All of this may be a bit hard to see because of the multiple insertion points
bug, but if you type distinctive text into each <textarea> and move the
insertion point back from the end in each it is easier; shrinking the
browser window vertically until less than 2 <textarea>s fit also helps.)

Changing summary from "Tabbing through TEXTAREA boxes inserts tab" to
"Cycling through TEXTAREAs in tabindex order messes up"

Tested with:
1999-11-25-09-M12 nightly binary on Windows NT

Comment 8

[buster]

fixed in M13.  The caret doesn't show up, that's a saari/hyatt focus bug.  I 
think they have several filed already on that problem.

Comment 9

[Chris Petersen]

With the Jan 31 build (2000013111), this problem is still occuring. Using the Tab 
key to cycle through the fields will move the cursor one tab space. Tested on Mac 
OS 9, Win 98, and Win NT. 

Comment 10

[Sean Richardson]

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

Comment 11

[Sean Richardson]

Retesting with 2000-02-11-09-M14 nightly binary on Windows NT 4.0,
this is misbehaving in yet another variation on what's been seen before.

Steps to reproduce:
1. Load the URL above.
2. Click in the text above the TEXTAREAs.
3. Type [TAB], a, [TAB], b, [TAB], c, and so on for at least eight repetitions.

Actual Results:
The first four [TAB] keystrokes advance the focus to each TEXTAREA in turn;
the first four letters end up in the TEXTAREAs in their TABINDEX sequence order.
The fifth [TAB] keystroke navigates to the mailto: <A> link at the bottom of the 
page; and fifth letter does nothing. The sixth [TAB] positions the focus back
in the first TEXTAREA, with the caret appearing to be positioned one character
to the right of the existing letter, but when the sixth letter is typed, it
is positioned a tabstop to the right. The same continues to happen in the other
TEXTAREAs.

Expected Results:
The letters appear in the TEXTAREAs in TABINDEX order, except every fifth, and
with no whitespace between them within each TEXTAREA.

Comment 12

[buster]

moving non-PDT+ M14 bugs to M15.

Comment 13

[Sean Richardson]

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

Comment 14

[rickg]

moving all buster m15 bugs to m16.

Comment 15

[buster]

I need someone else to own this.  I don't think it's an editor problem per se, 
maybe a joki problem?

Comment 16

[rickg]

Joki is way too overloaded. Rod, can you please take a look?

Comment 17

[rods (gone)]

I tried to lok at this and couldn't figure out what was being done in the 
eventstatemanager. I think there is already a bug on this that would be a dup of 
this bug.

Comment 18

[Jesse Ruderman]

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

Comment 19

[Chris Petersen]

Tabindex should work in text fields since may users fill out forms on the net. 
Added nsbeta2 to keywords.

Comment 20

[joki (gone)]

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

Comment 21

[Katcha Da]

Verified that this is a duplicate of bug 36217 and marking as such.