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.

Setting all current Open/Normal to M4.

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

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

fix summary

moved to M11

added rod to the cc list. Set to M14.

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

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.

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.

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

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.

moving non-PDT+ M14 bugs to M15.

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

moving all buster m15 bugs to m16.

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

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

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.

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

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

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

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