Closed Bug 244179 Opened 17 years ago Closed 16 years ago
tabindex not honoured if form element is focused via <LABEL>
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.
Testcase with three text inputs. The text of the label next to each input element shows its tabindex.
WFM firefox windows 20040522 trunk
I see this on LInux 2004063006
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Neo, you want this one?
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 on attachment 154745 [details] [diff] [review] patch this fix don't break 136495. however, i haven't got response from bryner
Attachment #154745 - Flags: review?(aaronleventhal)
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.
Attachment #154745 - Flags: review?(aaronleventhal) → review-
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 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)
Attachment #154772 - Flags: review?(neo.liu) → review+
(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.
Attachment #154772 - Flags: superreview?(bryner) → superreview+
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. email@example.com, 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
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.