Created attachment 406533 [details] onclick behavior test Steps to reproduce the problem: Try this: ```js input = document.createElement("input"); input.disabled = true; input.onclick = console.log input.dispatchEvent(new MouseEvent("click")); ``` What is the expected behavior? A click event should fire after a dispatchEvent call What went wrong? It never fires on a disabled input element. Did this work before? N/A Does this work in other browsers? Yes, in Firefox It must fire onclick per the spec. Related discussion: https://github.com/whatwg/html/pull/5805#issuecomment-672960163
<rdar://problem/67030950>
Created attachment 413195 [details] WIP Patch
Hey, just looking at the patch, it doesn't seem to match the intention of the spec. The idea is that if the *user* clicks one of these, then it's disabled and the event isn't delivered: > A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element. Similarly, click() doesn't go through on disabled elements: > If this element is a form control that is disabled, then return. But any dispatchEvent(new MouseEvent("click")) should always fire "click" handlers. That's just part of general DOM event dispatch, and not related to checkboxes or radio buttons specifically, or to disabledness. Hope this helps!
(In reply to Domenic Denicola from comment #3) > Hey, just looking at the patch, it doesn't seem to match the intention of > the spec. The idea is that if the *user* clicks one of these, then it's > disabled and the event isn't delivered: > > > A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element. > > Similarly, click() doesn't go through on disabled elements: > > > If this element is a form control that is disabled, then return. > > But any dispatchEvent(new MouseEvent("click")) should always fire "click" > handlers. That's just part of general DOM event dispatch, and not related to > checkboxes or radio buttons specifically, or to disabledness. > > Hope this helps! It is not clear to me that the patch does not match what you're saying. I guess I need to add more tests to confirm.
Created attachment 413203 [details] WIP Patch
(In reply to Chris Dumez from comment #4) > (In reply to Domenic Denicola from comment #3) > > Hey, just looking at the patch, it doesn't seem to match the intention of > > the spec. The idea is that if the *user* clicks one of these, then it's > > disabled and the event isn't delivered: > > > > > A form control that is disabled must prevent any click events that are queued on the user interaction task source from being dispatched on the element. > > > > Similarly, click() doesn't go through on disabled elements: > > > > > If this element is a form control that is disabled, then return. > > > > But any dispatchEvent(new MouseEvent("click")) should always fire "click" > > handlers. That's just part of general DOM event dispatch, and not related to > > checkboxes or radio buttons specifically, or to disabledness. > > > > Hope this helps! > > It is not clear to me that the patch does not match what you're saying. I > guess I need to add more tests to confirm. I added more tests based on your comments and they all seem to pass. Please let me know if I missed something.
The case I was thinking of was that .dispatchEvent() should also work on disabled text inputs or textareas or selects. My reading of the current patch is that it disallows click events on all disabled inputs, unless it's a checkbox or radio button. It doesn't seem to (from my uninformed skimming) differentiate between dispatchEvent(), click(), and user clicks. Whereas, the spec differentiates between those three categories. But does not differentiate between checkbox/radio, and any other elements.
Created attachment 413218 [details] WIP Patch
Created attachment 413219 [details] WIP Patch
Created attachment 413220 [details] WIP Patch
Created attachment 413306 [details] Patch
Committed r269452: <https://trac.webkit.org/changeset/269452> All reviewed patches have been landed. Closing bug and clearing flags on attachment 413306 [details].