Closed Bug 7554 Opened 25 years ago Closed 25 years ago

<label> doesn't work with <button> (should execute script)

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: Brade, Assigned: pollmann)

References

Details

(Whiteboard: Possible fix. Getting code review and approval.)

Attachments

(1 file)

Given the following html, notice that clicking on any of the labels for the buttons will not cause a javascript error (in this case, a missing handler). However, clicking the buttons themselves will produce the javascript error. Also, I would expect that the button would depress and release with the mousedown on the label (as if it had been clicked) but the spec may not agree with me :-) <html> <head> <title> select disable test </title> <script> function wronghandler() { } </script> </head> <body> <form> <label for="b1"> Button: </label> <button type="button" id="b1" onclick="clickbtn()">Button</button> <br/> <label for="b2"> Button: </label> <button type="submit" id="b2" onclick="clickbtn()">Submit</button> <br/> <label for="b3"> Button: </label> <button type="reset" id="b3" onclick="clickbtn()">Reset</button> </form> </body> </html>
Assignee: karnaze → evaughan
Eric, it you don't want this please reassign to Pollmann.
Assignee: evaughan → pollmann
Status: NEW → ASSIGNED
Target Milestone: M9
Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.
The HTML 4 spec implies that clicking on a label associated with a form control should do the same thing as if the control had an associated access key which had been activated (s 17.9.1). Having said that, the section on access keys (s 17.11.2) does not state what should happen when a button is accessed via an access key or label -- should the button be activated, or should it just receive focus? I would tend to say that buttons be activated in this case, since this is what a user would expect an access key to do in this situation. Whatever is decided should be consistant with Submit or Reset buttons. See bug 7292 for a similar case.
Attached file Kathy's test case (deleted) —
*** Bug 7292 has been marked as a duplicate of this bug. ***
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Whiteboard: Possible fix. Getting code review and approval.
From 7292 - my fix: Index: nsHTMLLabelElement.cpp =================================================================== RCS file: /cvsroot/mozilla/layout/html/content/src/nsHTMLLabelElement.cpp,v retrieving revision 1.15 diff -r1.15 nsHTMLLabelElement.cpp 31a32,33 > #include "nsIDocument.h" > #include "nsIDOMHTMLDocument.h" 296c298 < return mInner.HandleDOMEvent(aPresContext, aEvent, aDOMEvent, --- > nsresult rv = mInner.HandleDOMEvent(aPresContext, aEvent, aDOMEvent, 297a300,328 > if (NS_SUCCEEDED(rv)) { > nsAutoString elementId; > rv = GetHtmlFor(elementId); > if (NS_SUCCEEDED(rv)) { > nsIDocument* doc = nsnull; > rv = mInner.GetDocument(doc); // Strong > if (NS_SUCCEEDED(rv)) { > nsIDOMHTMLDocument* htmldoc = nsnull; // Strong > rv = doc->QueryInterface(nsIDOMHTMLDocument::GetIID(),(void**)&htmldoc); > if (NS_SUCCEEDED(rv)) { > nsIDOMElement* element = nsnull; // Strong > rv = htmldoc->GetElementById(elementId, &element); > if (NS_SUCCEEDED(rv)) { > nsIContent* content = nsnull; // Strong > rv = element->QueryInterface(nsIContent::GetIID(),(void**)&content); > if (NS_SUCCEEDED(rv)) { > content->HandleDOMEvent(aPresContext, aEvent, aDOMEvent, > aFlags, aEventStatus); > NS_RELEASE(content); > } > NS_RELEASE(element); > } > NS_RELEASE(htmldoc); > } > NS_RELEASE(doc); > } > } > } > return rv; 299d329 <
Kathy, would it be okay to move this to M11 to get it off of the M10 radar? It is not a crasher, and I can check my fix in first thing M11.
Target Milestone: M10 → M11
move to M11 for pollmann
I've improved this fix to also handle the case where a label has no FOR attribute, but is for a child element that it contains. I'll try to get this in for M11.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Just checked in a fix. Note bug 16810 is not fixed by this checkin.
QA Contact: phillip → chrisd
QA Contact: chrisd → petersen
Status: RESOLVED → VERIFIED
Using 12/1 build, verified bug fixed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: