WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
UNCONFIRMED
34465
DOM events that capture should register to elements that contain a disabled form element
https://bugs.webkit.org/show_bug.cgi?id=34465
Summary
DOM events that capture should register to elements that contain a disabled f...
fgasper
Reported
2010-02-01 22:22:44 PST
(Copied from Firefox bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=541110
) 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>.
Attachments
Add attachment
proposed patch, testcase, etc.
Ahmad Saleem
Comment 1
2022-07-31 06:06:15 PDT
I get following behavior based on test case from
Comment 0
changed into JSFiddle below: Link -
https://jsfiddle.net/0ycrkt69/show
** Safari 15.6 on macOS 12.5 ** Click on any where on <div> triggers dialog showing "Clicked" and when you click on portion of disabled <input> within <div>, it also trigger "Clicked" dialog. NOTE - Separate from bug, the disabled state color in macOS 12.6 is different from other browser and does not show clearly whether it is disabled or not. ** Chrome Canary 106 ** Click on any where on <div> triggers dialog showing "Clicked" and when you click on portion of disabled <input> within <div>, it also trigger "Clicked" dialog. SAME As Safari ** Firefox Nightly 105 ** Click on any where on <div> triggers dialog showing "Clicked" and when you click on portion of disabled <input> within <div>, it DOES NOT trigger "Clicked" dialog like other browsers. _________ I am not clear on web-spec but Firefox behavior is different here from other two browsers. Firefox bug as per
Comment 0
is still open but it is deemed to be duplicate of this Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=329509
Which indicates that it has been fixed. _______ Appreciate if someone can mark this bug as "RESOLVED INVALID" or "Web-Spec" bug accordingly. Just wanted to share updated testing results. Thanks!
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug