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

Status: VERIFIED FIXED

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

Description

[Ian Richards]

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

[Richard Zach]

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.

Comment 2

[Richard Zach]

Attachment: Testcase

Comment 3

[karnaze (gone)]

Reassigning to Saari.

Comment 4

[saari (gone)]

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.

Comment 5

[Antti Näyhä]

*** Bug 29662 has been marked as a duplicate of this bug. ***

Comment 6

[saari (gone)]

Move to M15

Comment 7

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 8

[Peter Trudelle]

moving to m18. This works in XUL, not in HTML. Does that mean Joki should have 
this?

Comment 9

[saari (gone)]

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

Comment 10

[Peter Trudelle]

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Comment 11

[Antti Näyhä]

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

Comment 12

[Peter Trudelle]

future

Comment 13

[Karl Ove Hufthammer]

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

Comment 14

[Braden]

Removing 4xp--that keyword tracks parity with Communicator 4.x.

Comment 15

[bsharma]

Updating QA contact.

Comment 16

[Loco]

*** Bug 47230 has been marked as a duplicate of this bug. ***

Comment 17

[saari (gone)]

targeting mozilla 1.0 for correctness

Comment 18

[Loco]

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

Comment 19

[Karl Ove Hufthammer]

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

Comment 20

[Karl Ove Hufthammer]

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

[Karl Ove Hufthammer]

Attachment: Test case showing *both* ways labels can be assigned to other form elements.

Comment 22

[rods (gone)]

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

Comment 23

[rods (gone)]

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

[Vladimir Ermakov]

QA Contact Update

Comment 25

[Tim Powell]

Added access keyword, cc to me.

Comment 26

[basic]

Attachment: testcase showing targets during events

Comment 27

[basic]

Attachment: testcase showing targets when using accesskey

Comment 28

[basic]

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?

Comment 29

[basic]

Attachment: testcase showing targets when using accesskey

this one shows the event phase

Comment 30

[basic]

Attachment: testcase showing targets and event phases when using accesskey or clicking

Comment 31

[Pavol Vaskovic]

There is the same problem with <label>s and <select>s - bug 107621 .

Comment 32

[Christopher Hoess (gone)]

*** Bug 106344 has been marked as a duplicate of this bug. ***

Comment 33

[Brendan Eich [:brendan]]

h

Comment 34

[Nicolás Lichtmaier]

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

[Eli Friedman]

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

Comment 36

[Daniel Wang]

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

[Lachlan]

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

[James Green]

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

[Gérard Talbot]

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

Comment 40

[Jess Collicott]

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

Comment 41

[Emmanuel Bourg]

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

Comment 42

[Adam Hauner]

reopen to re-resolve

Comment 43

[Adam Hauner]

Marking WFM regarding several last comments.

Comment 44

[Vladimir Ermakov]

verifying on build 2002-07-25-14-trunk win2k

Comment 45

[Pavol Vaskovic]

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

[Jonas Jørgensen]

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

Comment 47

[Bill Mason]

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.

Comment 48

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 49

[John Keiser (jkeiser)]

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

[Bill Mason]

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.

Comment 51

[Christopher Aillon (sabbatical, not receiving bugmail)]

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!

Comment 52

[Bill Mason]

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

Comment 53

[Gérard Talbot]

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

[Jonas Jørgensen]

> 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

[Vladimir Ermakov]

verifying build 2002-09-10-08 trunk win 2k

Comment 56

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Changing mozilla1.0.2 to fixed1.0.2.  See bug 96813 comment 47.

Comment 57

[Bill Mason]

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

[Amarendra Hanumanula]

Verified on the branch build 20021008 on WIN2K, Linux 7.1 and macosx 10.1

Comment 59

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381