Bug 215461 - <input disabled> does not fire click events after dispatchEvent
Summary: <input disabled> does not fire click events after dispatchEvent
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on: 218570
Blocks:
  Show dependency treegraph
 
Reported: 2020-08-13 12:53 PDT by Kagami Sascha Rosylight
Modified: 2020-11-05 11:12 PST (History)
15 users (show)

See Also:


Attachments
onclick behavior test (276 bytes, text/html)
2020-08-13 12:53 PDT, Kagami Sascha Rosylight
no flags Details
WIP Patch (3.98 KB, patch)
2020-11-04 12:51 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
WIP Patch (8.10 KB, patch)
2020-11-04 13:32 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
WIP Patch (3.27 KB, patch)
2020-11-04 15:57 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
WIP Patch (7.40 KB, patch)
2020-11-04 15:58 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
WIP Patch (7.18 KB, patch)
2020-11-04 15:59 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (12.01 KB, patch)
2020-11-05 09:02 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kagami Sascha Rosylight 2020-08-13 12:53:03 PDT
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
Comment 1 Radar WebKit Bug Importer 2020-08-13 17:48:12 PDT
<rdar://problem/67030950>
Comment 2 Chris Dumez 2020-11-04 12:51:18 PST
Created attachment 413195 [details]
WIP Patch
Comment 3 Domenic Denicola 2020-11-04 13:13:16 PST
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!
Comment 4 Chris Dumez 2020-11-04 13:19:10 PST
(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.
Comment 5 Chris Dumez 2020-11-04 13:32:10 PST
Created attachment 413203 [details]
WIP Patch
Comment 6 Chris Dumez 2020-11-04 13:32:48 PST
(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.
Comment 7 Domenic Denicola 2020-11-04 13:40:47 PST
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.
Comment 8 Chris Dumez 2020-11-04 15:57:50 PST
Created attachment 413218 [details]
WIP Patch
Comment 9 Chris Dumez 2020-11-04 15:58:53 PST
Created attachment 413219 [details]
WIP Patch
Comment 10 Chris Dumez 2020-11-04 15:59:41 PST
Created attachment 413220 [details]
WIP Patch
Comment 11 Chris Dumez 2020-11-05 09:02:25 PST
Created attachment 413306 [details]
Patch
Comment 12 EWS 2020-11-05 11:12:27 PST
Committed r269452: <https://trac.webkit.org/changeset/269452>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 413306 [details].