The default bug view has changed. See this FAQ.

Clicking on <LABEL> doesn't put focus in INPUT field

VERIFIED FIXED in mozilla1.1alpha

Status

()

Core
Layout: Form Controls
P3
normal
VERIFIED FIXED
17 years ago
3 years ago

People

(Reporter: Ian Richards, Assigned: saari (gone))

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla1.1alpha
access, html4, sec508, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [HTML4-17.9.1])

Attachments

(3 attachments, 3 obsolete attachments)

(Reporter)

Description

17 years ago
Setup this small piece of html, I've not bothered with head body etc, but you
can if you wish.

<label for=test1>label one</label><input id=test1>
<label for=test2>label two</label><input id=test2>

Open the HTML document.

Click on the text "label one", then click on the text "label two".

I've tried two builds which give different and unexpected results.

Build ID 20000012520
Leaves you with a cursor blinking away in each input field.
If you're lucky you'll have one in the address bar too.

Build ID 20000022016
Clicking on the labels doesn't do anything in particular it doesn't move you to
the appropriate input field. There again you don't get multiple cursors either!

Comment 1

17 years ago
The multiple carets problem is fixed, I think.  So what's left is this: clicking
on a <label> should put the keyboard focus in the corresponding INPUT.  This
works for radio buttons (clicking on a LABEL corresponding to INPUT type=radio
selects the radio button.  Attaching a textcase.  Should probably be FORM
controls, reassigning to karnaze.
Assignee: rickg → karnaze
Status: UNCONFIRMED → NEW
Component: HTML Element → HTML Form Controls
Ever confirmed: true
Keywords: testcase
OS: Windows NT → All
QA Contact: petersen → ckritzer
Hardware: PC → All
Summary: <label for=...> either not working at all or causing two cursors. → Clicking on <LABEL> doesn't put focus in INPUT field

Comment 2

17 years ago
Created attachment 5547 [details]
Testcase

Comment 3

17 years ago
Reassigning to Saari.
Assignee: karnaze → saari
(Assignee)

Comment 4

17 years ago
Talked to joki, and it looks like the thing to do is special case label elements 
in nsEventStateManager::PostHandleEvent to set focus to what the label is 
pointing at instead of the label itself.
Status: NEW → ASSIGNED
Target Milestone: M14

Comment 5

17 years ago
*** Bug 29662 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 6

17 years ago
Move to M15
Target Milestone: M14 → M15
(Assignee)

Updated

17 years ago
Target Milestone: M15 → M16

Comment 7

17 years ago
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17

Comment 8

17 years ago
moving to m18. This works in XUL, not in HTML. Does that mean Joki should have 
this?
Target Milestone: M17 → M18
(Assignee)

Comment 9

17 years ago
Either joki or I can do this. It isn't really on one side or the other IMO.

Comment 10

17 years ago
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21

Comment 11

17 years ago
Adding 'html4' keyword - and '4xp' too, since the "explicit" label method works
in IE4/5.
Keywords: 4xp, html4

Comment 12

17 years ago
future
Target Milestone: M21 → Future

Comment 13

17 years ago
Since this already works in XUL, is it really very difficult to fix for HTML?

Comment 14

17 years ago
Removing 4xp--that keyword tracks parity with Communicator 4.x.
Keywords: 4xp

Updated

17 years ago
QA Contact: ckritzer → bsharma

Comment 15

17 years ago
Updating QA contact.

Comment 16

17 years ago
*** Bug 47230 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 17

17 years ago
targeting mozilla 1.0 for correctness
Target Milestone: Future → mozilla1.0

Updated

17 years ago
Blocks: 7954

Comment 18

17 years ago
Test case from above bug:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=13351

Comment 19

17 years ago
*** Bug 58536 has been marked as a duplicate of this bug. ***

Comment 20

17 years ago
Note that there are two ways you can assign labels to form elements in HTML.
Adding test case showing both (Mozilla fails both, IE >5 handles one of them).

Comment 21

17 years ago
Created attachment 20893 [details]
Test case showing *both* ways labels can be assigned to other form elements.

Comment 22

17 years ago
This isn't saari's bug, it my bug and I have the fix. taking bug

Comment 23

17 years ago
No, actually it is saari's bug, a good place to place a break point is on line 
835 of nsHTMLInputElement.cpp. It has to do with the event init'ing.

Comment 24

16 years ago
QA Contact Update
QA Contact: bsharma → vladimire

Updated

16 years ago
Keywords: access

Comment 25

16 years ago
Added access keyword, cc to me.
(Assignee)

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla0.9.9
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.1

Comment 26

16 years ago
Created attachment 56750 [details]
testcase showing targets during events

Comment 27

16 years ago
Created attachment 56753 [details]
testcase showing targets when using accesskey

Updated

16 years ago
Attachment #56750 - Attachment is obsolete: true

Comment 28

16 years ago
after some testing I think this should be fixed on the label side of rather than
the input. My reasoning is such. Currently when a label is "clicked" it sends a
"click" event to input[text]. input[text] does not do anything because "click"
does not do anything on the input[text] (or input[file] or input[password] or
textarea or select). Since the purpose of this is to cause the form control to
get focus why don't label pass a "focus" event instead?

Updated

15 years ago
Keywords: mozilla0.9.9

Comment 29

15 years ago
Created attachment 68079 [details]
testcase showing targets when using accesskey

this one shows the event phase
Attachment #56753 - Attachment is obsolete: true

Comment 30

15 years ago
Created attachment 68089 [details]
testcase showing targets and event phases when using accesskey or clicking
Attachment #68079 - Attachment is obsolete: true

Comment 31

15 years ago
There is the same problem with <label>s and <select>s - bug 107621 .
Keywords: mozilla0.9.9
Whiteboard: [HTML4-17.9.1]
*** Bug 106344 has been marked as a duplicate of this bug. ***
h

Comment 34

15 years ago
I've done it with XBL...with a:

<handlers>
	<handler event="click"
action="this.ownerDocument.getElementById(this.htmlFor).focus()"/>
</handlers>


Couldn't something like this be included in mozilla?
It's at: http://mazinger.technisys.com.ar/pruebas-nick/label.html

Comment 35

15 years ago
the link (#34) only works for the second element (on purpose?)

Comment 36

15 years ago
Is this the expected behavior? For all I know on Windows labels,
except for radio buttons and check boxes, are never clickable
objects. All labels do are describing input fields and maybe display
the access key, both mozilla do well (<label accesskey> does shift
focus to its <input> when the access key is pressed)

Comment 37

15 years ago
Try clicking on a label associated with a form field in IE. It passes focus to
the field. Even if this wasn't standard Windows, IE's widespread use makes it
standard web practice, and besides it's really useful and hardly detracts from
the interface.

Comment 38

15 years ago
I presume it would be extremely unlikely that any other behaviour could be
expected or possible. Actually it may be that the text in the label may be
hooked up to some javascript to open a popup window containing help for the
field; however that should be part of the event bubble and not interfere with
setting the window's focus.

Comment 39

15 years ago
Each test case in attachments 5547 , 20893 and 68089 WFM in Windows XP Pro with
build 2002072918.

Comment 40

15 years ago
WFM - Windows 2000; rv:1.1b; Gecko/20020730

Comment 41

15 years ago
It works for me as well now, using Mozilla 1.1b (Gecko/20020721) on Windows NT 4.0

Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 42

15 years ago
reopen to re-resolve
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 43

15 years ago
Marking WFM regarding several last comments.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → WORKSFORME

Comment 44

15 years ago
verifying on build 2002-07-25-14-trunk win2k
Status: RESOLVED → VERIFIED

Comment 45

15 years ago
Well. It works also for me in moz1.1b BUT - that means that this was fixed, so
correct resolution should be FIXED. Assignee had no time to mark as such?!

Comment 46

15 years ago
No, that means that this problem has gone away as a side-effect of some other
checkin, so correct resolution is WORKSFORME.

Comment 47

15 years ago
Reopening to request that this be explictly fixed on the 1.0 branch.  Currently
1.0.1 RC2 (build 2002082306) and the Netscape 7 final still have this bug.  I
believe it should be fixed there for both the accessibility and HTML 4
compliance rationales.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Bill, Fixed applies to the trunk only anyway.  If stuff isn't on the branch,
then we have different ways to nominate it.  But the first thing you need to do
is figure out what fixed this, so we can decide if we want to check it into the
branch.

I'm re-resolving as fixed.  Bill, if you happen to find out what fixed this,
please note it here and if you still want to nominate it, then add the
"mozilla1.0.2" keyword to the bug.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Keywords: mozilla1.0.2
Resolution: --- → FIXED
Bill, if you want to investigate, I suspect bug 96813 is what fixed this.  By
checking the nightly on 5/21 (should not work) versus 5/22, you should be able
to tell.  I am not sure, but there are no other FIXED bugs with "label" in the
summary over the last 4 months.

If it's really bug 96813, however, there would have to be pretty serious reasons
(like a topsite or something) to include it.  That patch is big.  HTML
compliance alone is not enough to put something in *after* a release unless that
compliance comes at a very low risk.

Comment 50

15 years ago
Well, nightlies that far back aren't on the FTP anymore and just aren't
available according to Asa, unless I happen to find someone who has a copy lying
around.

Nevertheless, I believe that the fix for bug 98613 is the patch that resolved
this bug.  David Baron notes that the patch makes fixes for giving focus from
labels to their form controls
(http://bugzilla.mozilla.org/show_bug.cgi?id=96813#c9).  I also ran a few tests
using some old milestones, which are the only builds in this date range still
available:

4/18: 1.0 RC1: LABEL is broken
5/21: fix for bug 98613 checked in
6/11: 1.1 alpha: LABEL is fixed

I realize it may not happen (having been forewarned), but I'm nominating this be
fixed in 1.0.2 for these reasons:

* Required to satisfy section 1944.22(n) of Section 508
<http://www.access-board.gov/sec508/guide/1194.22.htm#(n)>
* Required to fulfill checkpoint 12.4 of the Web Content Accessibility
Guidelines 1.0
<http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-associate-labels> and
checkpoint 1.4 of the current public draft of WCAG 2.0
<http://www.w3.org/WAI/GL/WCAG20/#use-style-to-emphasize>
* Germany will soon require WCAG level AA conformance for its federal government
sites, which would include checkpoint 12.4
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2002JulSep/0498.html>
* Ireland requires WCAG AA conformance <http://www.isc.ie/ninfo/conngm.html#6.3.2>
* Canada requires AA conformance
<http://lists.w3.org/Archives/Public/w3c-wai-ig/2002AprJun/0574.html>
* Required to satisfy checkpoints 8.1 and 8.2 of the WAI User Agent
Accessibility Guidelines
<http://www.w3.org/TR/UAAG10/guidelines.html#tech-implement-access-features>
* If N7 stays on the 1.0 branch, it can never achieve any of these.
* Parity with IE (and one ahead of Opera)

Added kw sec508. Making a blocker of bug 24413.
Blocks: 24413
Status: RESOLVED → REOPENED
Keywords: sec508
Resolution: FIXED → ---
Bill: As soon as a bug is fixed on the trunk, we resolve it FIXED.  If you want
something resolved on the branch, then the procedure is to add the keyword (but
do not reopen the bug).  Then try and find someone to track down the correct
patch (note, I am not volunteering).  Then e-mail drivers and request this (or
better yet, the bug that DID fix this) be approved for branch.  You should never
reopen a bug though if you know it is fixed on the trunk.  Thanks!
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 52

15 years ago
Thx.
This bug should be a WFM, by the way.

Comment 53

15 years ago
Christopher and Bill,

It's too bad that NS 7 was released and did not have the fix for this bug. 10
days before release (august 19th), I wrote in netscape.netscape7.windows
(subject line was "Final version Netscape 7.0" that 

Begin of excerpt:
-----------------
Now, if NS 7.0 final will be based on that build (and everything so far indicate
it will), then I'd like to report something which is quite unacceptable. Absence
of accessibility features which were working before and/or are working under
Mozilla1.1beta.
Coming from bug 28657
http://bugzilla.mozilla.org/show_bug.cgi?id=28657
(resolved at least 3 weeks ago): (...)
"Accessibility is a civil right."
"(...) offering a public service. That is unjustifiable discrimination, and
actionable, as AOL and IBM found out."
Can Netscape release Netscape 7.0 Final release without a complete support of
the accessibility features which worked under trunk
builds? I'm referring to bugs which were solved already, not bugs which have not
yet been fixed, solved, you know... (...)
--------------
end of excerpt

At the time, I did not know who to turn to. I still do not fully or perfectly
understand how Mozilla works (trunk, branch, review, checkins, etc..). If we
want to avoid a repetition of such mishappening, then all bugs related to
section 508 and accessibility should be marked, keyworded accordingly. For starters,

bug 106344 should also have the keywords: access , nsbranch+ and sec508

bug 84360 should also have the keywords: nsbranch+ , sec508 

etc...

The fact that NS 7.0 final release does not have more basic accessibility
features is very regrettable, embarassing, difficult to justify. Can Mozilla
make sure that such mishappening never occurs again?

Thanks for listening

Comment 54

15 years ago
> The fact that NS 7.0 final release does not have more basic accessibility
> features is very regrettable, embarassing, difficult to justify. Can Mozilla
> make sure that such mishappening never occurs again?

Whatever Netscape does is Netscape's decision and out of mozilla.org's control.
If you wish to complain about Netscape's decisions, use their Contact Us page:
http://wp.netscape.com/company/contacts/

Comment 55

15 years ago
verifying build 2002-09-10-08 trunk win 2k
Status: RESOLVED → VERIFIED
Changing mozilla1.0.2 to fixed1.0.2.  See bug 96813 comment 47.
Keywords: mozilla1.0.2 → fixed1.0.2

Comment 57

15 years ago
This was fixed yesterday on the branch in bug 96813.  Thx to everyone I talked
with who walked me thru the process of seeing this fix happen on the branch.  It
is much appreciated.

Comment 58

15 years ago
Verified on the branch build 20021008 on WIN2K, Linux 7.1 and macosx 10.1
Keywords: fixed1.0.2 → verified1.0.2

Updated

14 years ago
Blocks: 41368
You need to log in before you can comment on or make changes to this bug.