244179 - tabindex not honoured if form element is focused via <LABEL>

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[nick]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

See below

Reproducible: Always
Steps to Reproduce:
1. Define a <LABEL> for a form element with a tabindex
2. Click on the label to focus the text element
3. Press the TAB key

Actual Results:  
The next form element in document order is focused.

Expected Results:  
The form element with the subsequent tabindex should be focused.

Comment 1

[nick]

Attachment: Testcase

Testcase with three text inputs. The text of the label next to each input
element shows its tabindex.

Comment 2

[Bernard Alleysson]

WFM firefox windows 20040522 trunk

Comment 3

[Jesiah S]

I see this on LInux 2004063006

Comment 4

[Aaron Leventhal]

Confirming
Mozilla 1.8a2
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040625

To see the bug, first click on one of the labels and then tab.

Comment 5

[Aaron Leventhal]

Neo, you want this one?

Comment 6

[Nian Liu(n/a in a long time)]

Attachment: test patch( far away beyond finish )

Brian, could you please explain why "nodeValue.Length() == *aStartOffset" is
needed which is submitted by you related to bug 136495. startOffset could be
different due to click position different.

Comment 7

[Nian Liu(n/a in a long time)]

Attachment: patch

Comment 8

[Nian Liu(n/a in a long time)]

Comment on attachment 154745 [details] [diff] [review]
patch

this fix don't break 136495. however, i haven't got response from bryner

Comment 9

[Aaron Leventhal]

Comment on attachment 154745 [details] [diff] [review]
patch

Bryner didn't add that line to GetDocSelectionLocation() i n the bug you
mention -- that code was from me. When we look for the location of the current
selection, we return the next node/frame if the caret is at the end of a text
node/frame.

Comment 10

[Aaron Leventhal]

Attachment: In GetDocSelectionLocation, don't return selection in a <label> because we should tab relative to focus when selection is inside label

Comment 11

[Aaron Leventhal]

Comment on attachment 154764 [details] [diff] [review]
In GetDocSelectionLocation, don't return selection in a <label> because we should tab relative to focus when selection is inside label

Neo, thanks for the previous patch which showed me where the problem was.
Hunting down the actual problem is most of the work :)

Comment 12

[Aaron Leventhal]

Attachment: Correct patch

Comment 13

[Nian Liu(n/a in a long time)]

Comment on attachment 154772 [details] [diff] [review]
Correct patch

btw
Aaron, is there a easy way to find who checked in which code? i used to use cvs
blame and seems i can't use it correctly(that's why i think the code was
checked in by bryner)

Comment 14

[Aaron Leventhal]

(In reply to comment #13)
> Aaron, is there a easy way to find who checked in which code? i used to use cvs
> blame and seems i can't use it correctly(that's why i think the code was
> checked in by bryner)

Neo, usually that works but in this case I checked the bug that he used to check
it in under, and there you can see that he changed those lines for
whitespace-only reasons.

Comment 15

[Aaron Leventhal]

C:\moz\mozilla\content\events\src>cvs ci -m "Bug 244179. Tabindex not honoured
if form element is focused via <label>. Buggy part of code pinpointed by Nian
Liu. r=[e-mail], sr=bryner" nsEventStateManager.cpp
Checking in nsEventStateManager.cpp;
/cvsroot/mozilla/content/events/src/nsEventStateManager.cpp,v  <-- 
nsEventStateManager.cpp
new revision: 1.516; previous revision: 1.515
done