Closed Bug 28657 Opened 21 years ago Closed 18 years ago

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


(Core :: Layout: Form Controls, defect, P3)






(Reporter: irichard, Assigned: saari)



(Keywords: access, html4, testcase, Whiteboard: [HTML4-17.9.1])


(3 files, 3 obsolete files)

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!
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
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
Attached file Testcase
Reassigning to Saari.
Assignee: karnaze → saari
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.
Target Milestone: M14
*** Bug 29662 has been marked as a duplicate of this bug. ***
Move to M15
Target Milestone: M14 → M15
Target Milestone: M15 → M16
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17
moving to m18. This works in XUL, not in HTML. Does that mean Joki should have 
Target Milestone: M17 → M18
Either joki or I can do this. It isn't really on one side or the other IMO.
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Adding 'html4' keyword - and '4xp' too, since the "explicit" label method works
in IE4/5.
Keywords: 4xp, html4
Target Milestone: M21 → Future
Since this already works in XUL, is it really very difficult to fix for HTML?
Removing 4xp--that keyword tracks parity with Communicator 4.x.
Keywords: 4xp
QA Contact: ckritzer → bsharma
Updating QA contact.
*** Bug 47230 has been marked as a duplicate of this bug. ***
targeting mozilla 1.0 for correctness
Target Milestone: Future → mozilla1.0
Blocks: html4.01
*** Bug 58536 has been marked as a duplicate of this bug. ***
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).
This isn't saari's bug, it my bug and I have the fix. taking bug
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.
QA Contact Update
QA Contact: bsharma → vladimire
Keywords: access
Added access keyword, cc to me.
Target Milestone: mozilla1.0 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.1
Attached file testcase showing targets during events (obsolete) —
Attachment #56750 - Attachment is obsolete: true
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?
Keywords: mozilla0.9.9
this one shows the event phase
Attachment #56753 - Attachment is obsolete: true
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. ***
I've done it with XBL...with a:

	<handler event="click"

Couldn't something like this be included in mozilla?
It's at:
the link (#34) only works for the second element (on purpose?)
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)
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.
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.
Each test case in attachments 5547 , 20893 and 68089 WFM in Windows XP Pro with
build 2002072918.
WFM - Windows 2000; rv:1.1b; Gecko/20020730
It works for me as well now, using Mozilla 1.1b (Gecko/20020721) on Windows NT 4.0

Closed: 18 years ago
Resolution: --- → FIXED
reopen to re-resolve
Resolution: FIXED → ---
Marking WFM regarding several last comments.
Closed: 18 years ago18 years ago
Resolution: --- → WORKSFORME
verifying on build 2002-07-25-14-trunk win2k
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?!
No, that means that this problem has gone away as a side-effect of some other
checkin, so correct resolution is WORKSFORME.
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.
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

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.
Closed: 18 years ago18 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.
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

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
(  I also ran a few tests
using some old milestones, which are the only builds in this date range still

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
* Required to fulfill checkpoint 12.4 of the Web Content Accessibility
Guidelines 1.0
<> and
checkpoint 1.4 of the current public draft of WCAG 2.0
* Germany will soon require WCAG level AA conformance for its federal government
sites, which would include checkpoint 12.4
* Ireland requires WCAG AA conformance <>
* Canada requires AA conformance
* Required to satisfy checkpoints 8.1 and 8.2 of the WAI User Agent
Accessibility Guidelines
* 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: uaag
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!
Closed: 18 years ago18 years ago
Resolution: --- → FIXED
This bug should be a WFM, by the way.
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
(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
Coming from bug 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 


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
> 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's control.
If you wish to complain about Netscape's decisions, use their Contact Us page:
verifying build 2002-09-10-08 trunk win 2k
Changing mozilla1.0.2 to fixed1.0.2.  See bug 96813 comment 47.
Keywords: mozilla1.0.2fixed1.0.2
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.
Verified on the branch build 20021008 on WIN2K, Linux 7.1 and macosx 10.1
Blocks: robin's
You need to log in before you can comment on or make changes to this bug.