Open
Bug 541110
Opened 14 years ago
Updated 2 years ago
DOM events that capture should register to elements that contain a disabled form element
Categories
(Core :: DOM: Events, defect)
Core
DOM: Events
Tracking
()
NEW
People
(Reporter: felipe, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: testcase)
Attachments
(1 file)
|
377 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729)
If I click on a disabled <input> element, and the "click" listener is registered on a containing element (say, a <div>) and set to capture, the containing element should receive the click.
The spec only says that disabled form elements do not receive DOM events; it doesn’t say that containing elements can’t receive those events on capture. It seems both counterintuitive and counter-productive for Moz to behave this way; for the many cases where we *would* want a disabled <input> to receive a click (e.g. to re-enable the control), a simple solution would be to wrap the <input> inside a <span>.
It makes sense for *bubble* events to fail in this way, but not for capture.
Reproducible: Always
Steps to Reproduce:
Load this code:
<html>
<body>
<div id="capture_div" style="background-color: lightgreen">
<br />
<br />
<input type="text" value="disabled" disabled="disabled" />
<br />
<br />
</div>
<script type="text/javascript">
document.getElementById('capture_div').addEventListener(
'click',
function(e) {
alert("clicked");
},
true
);
</script>
</body>
</html>
-----------
Then, click in the green-colored div, anyplace but over the <input>.
Actual Results:
After clicking anyplace in the <div> not over the <input>, an alert box appears. But if you click over the <input>, even though you are still within the <div> and the event is set to capture (i.e. to go to container elements first) and registered to the <div>, no alert happens.
Expected Results:
The alert should pop up after clicking anyplace in the <div>.
WebKit and Opera behave the same way. IE is a non-issue since they don’t support event capture.
Incidentally, this prevents user interfaces from receiving clicks over disabled <select> boxes and activating those <select>s. Thus: x Foo o Bar o <select> In the above, “Foo” is checked, while the other two radio buttons are unchecked. This setup is familiar from many interfaces; intuitively, we expect that the <select> is grayed out when its radio button is not checked. It’s also a reasonable expectation that clicking on that disabled <select> will enable it and check the associated radio button, in the same way that clicking on the “Bar” label will check that radio button. Event capture is the only way to do this, and it should work in this case since the click doesn’t reach the disabled element until after it should have gone through the containing div.
OS: Windows XP → All
Hardware: x86 → All
|
||
Comment 2•13 years ago
|
||
|
|
||
Comment 3•13 years ago
|
||
Repro'd with Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110131 Firefox/4.0b11pre ID:20110131030335
Keywords: testcase
Version: unspecified → Trunk
|
|
||
Comment 4•12 years ago
|
||
Still an Issue with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20121202 Firefox/20.0 ID:20121202030723 (In reply to Felipe from comment #0) > WebKit and Opera behave the same way. IE is a non-issue since they don’t > support event capture. MSIE 10 gives an Alert Box too.
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 5•9 years ago
|
||
Looks like a duplicate of bug 329509, marking as a dependency for now.
Depends on: 329509
|
||
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•