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.

Reassigning to 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.

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

Move to M15

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

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

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+

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

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.

Updating QA contact.

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

targeting mozilla 1.0 for correctness

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

*** 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

Added access keyword, cc to me.

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?

this one shows the event phase

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

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

h

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

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

reopen to re-resolve

Marking WFM regarding several last comments.

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.

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.

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 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.

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!

Thx. 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 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

> 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/

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

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

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