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)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: Brade, Assigned: pollmann)
References
Details
(Whiteboard: Possible fix. Getting code review and approval.)
Attachments
(1 file)
(deleted),
text/html
|
Details |
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>
Updated•25 years ago
|
Assignee: karnaze → evaughan
Comment 1•25 years ago
|
||
Eric, it you don't want this please reassign to Pollmann.
Updated•25 years ago
|
Assignee: evaughan → pollmann
Assignee | ||
Updated•25 years ago
|
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.
Comment 3•25 years ago
|
||
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.
Assignee | ||
Comment 4•25 years ago
|
||
Assignee | ||
Updated•25 years ago
|
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Whiteboard: Possible fix. Getting code review and approval.
Assignee | ||
Comment 6•25 years ago
|
||
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
<
Assignee | ||
Comment 7•25 years ago
|
||
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.
Reporter | ||
Updated•25 years ago
|
Target Milestone: M10 → M11
Reporter | ||
Comment 8•25 years ago
|
||
move to M11 for pollmann
Assignee | ||
Comment 9•25 years ago
|
||
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.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•25 years ago
|
||
Just checked in a fix. Note bug 16810 is not fixed by this checkin.
Updated•25 years ago
|
QA Contact: chrisd → petersen
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 11•25 years ago
|
||
Using 12/1 build, verified bug fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•