Cycling through TEXTAREAs in tabindex order messes up

VERIFIED DUPLICATE of bug 36217

Status

()

Core
Layout
P4
normal
VERIFIED DUPLICATE of bug 36217
19 years ago
18 years ago

People

(Reporter: bkdelong, Assigned: joki (gone))

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: troy → karnaze

Updated

19 years ago
Assignee: karnaze → kmcclusk

Comment 1

19 years ago
Setting all current Open/Normal to M4.

Comment 2

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

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Target Milestone: M4 → M5

Updated

19 years ago
Target Milestone: M5 → M7

Updated

19 years ago
Target Milestone: M7 → M9

Updated

19 years ago
Target Milestone: M9 → M10

Updated

19 years ago
Assignee: kmcclusk → buster
Status: ASSIGNED → NEW
Steve, I'm re-assigning this to you, You can use it as a test case for the
ender-based text fields.

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Summary: Tabbing through TEXTAREA boxes causes cursor to move → Tabbing through TEXTAREA boxes inserts tab

Comment 4

19 years ago
fix summary

Comment 5

19 years ago
moved to M11

Updated

19 years ago
Target Milestone: M11 → M14

Comment 6

19 years ago
added rod to the cc list.  Set to M14.

Updated

18 years ago
Summary: Tabbing through TEXTAREA boxes inserts tab → Cycling through TEXTAREAs in tabindex order messes up

Comment 7

18 years ago
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

18 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 9

18 years ago
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. 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 10

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

Comment 11

18 years ago
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

18 years ago
moving non-PDT+ M14 bugs to M15.
Target Milestone: M14 → M15

Comment 13

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

Comment 14

18 years ago
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16

Comment 15

18 years ago
I need someone else to own this.  I don't think it's an editor problem per se, 
maybe a joki problem?
Assignee: buster → rickg
Status: REOPENED → NEW

Comment 16

18 years ago
Joki is way too overloaded. Rod, can you please take a look?
Assignee: rickg → rods

Comment 17

18 years ago
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.
Assignee: rods → joki

Comment 18

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

Comment 19

18 years ago
Tabindex should work in text fields since may users fill out forms on the net. 
Added nsbeta2 to keywords.
Keywords: nsbeta2
(Assignee)

Comment 20

18 years ago

*** This bug has been marked as a duplicate of 36217 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 21

18 years ago
Verified that this is a duplicate of bug 36217 and marking as such.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.