I think my change incorrectly allows all mouse clicks to mutate checkboxes/radios. The intention here is:

• Physical mouse click (trusted click event): no mutation
• .click() (untrusted event): no mutation
• click from<label> (untrusted event): no mutation
• direct.dispatchEvent(new MouseEvent("click")) (untrusted event): mutation

I'll think more about this.

I think prohibiting physical mouse clicks is done at a different layer:https://html.spec.whatwg.org/#enabling-and-disabling-form-controls:-the-disabled-attribute says

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.

I think my change incorrectly allows all mouse clicks to mutate checkboxes/radios. The intention here is:

So, is this intention met by the current PR? Let me try to summarize; please correct anything I get wrong.

• Physical mouse click (trusted click event): no mutation

Handled byhttps://html.spec.whatwg.org/#enabling-and-disabling-form-controls:-the-disabled-attribute

Not yet tested inweb-platform-tests/wpt#24975.

• .click() (untrusted event): no mutation

Handled byhttps://html.spec.whatwg.org/#dom-click

Tested inweb-platform-tests/wpt#24975.

• click from<label> (untrusted event): no mutation

The spec is not precise about label activation behavior one way or another.https://html.spec.whatwg.org/#the-label-element says

The label element's exact default presentation and behavior, in particular what its activation behavior might be, if anything, should match the platform's label behavior.

and discusses examples of firing clicks on the element. So hmm.

My suggestion is that we don't touch this area for now. We could consider improving the requirements there in general, but as-is, we can't make strong assertions. As such, I think we should remove the label tests fromweb-platform-tests/wpt#24975.

direct.dispatchEvent(new MouseEvent("click")) (untrusted event): mutation

This is what this PR fixes, by adding an exception in the activation behavior for checkboxes and radios.

This is tested inweb-platform-tests/wpt#24975.

Thanks for the details! Yes, the current PR should be sufficient then.

I agree that the label thing should be solved separately. I'll file another bug.

Does the current spec define what should be done here? (Edit: fixed the example to disable the element)

varinput=document.createElement("input");input.type="checkbox";input.disabled=true;input.onclick=console.log// Firefox: a log, Chrome: no loginput.dispatchEvent(newMouseEvent("click"));

There are proses to prevent dispatching events as you mentioned, but I'm not seeing things to prevent onclick for already dispatched events.

The spec currently says that should be logged. I believe not-logging would require changes to event dispatch, which I'd like to avoid.

Based on the test results (Firefox,Chrome,Safari it seems that this patch's semantics match Firefox and Safari, but not Chrome. Could you file a Chrome bug and update the OP? Then this should be ready to merge, as it has 2 implementer support.

/cc@mfreed7 since it seems like not all browsers agree here, despite his comment in#5000 (comment).

Your web platform tests also add tests for the bug discussed in#5805 (comment), which show Firefox aligned to the spec while WebKit and Chrome are not. If you were up for filing separate bugs for those, that would be ideal, but it isn't directly tied to this PR. Alternately we could hold off, and have a separate spec discussion about whether we want to modify the event dispatching algorithm in that way... I hope we don't modify it though, so icky.

Based on the test results (Firefox,Chrome,Safari it seems that this patch's semantics match Firefox and Safari, but not Chrome. Could you file a Chrome bug and update the OP? Then this should be ready to merge, as it has 2 implementer support.

That's very weird, as it passes on my local environment, on both Ubuntu and Windows. You can copy-paste this to try it yourself:

varinput=document.createElement("input");input.type="checkbox";input.disabled=true;input.dispatchEvent(newMouseEvent("click"));input.checked// true

I'll remove the onclick tests for now and file a new issue. Actually I'll just file browser bugs since we hope we don't need to modify the spec here.

Edit: Filedhttps://bugs.chromium.org/p/chromium/issues/detail?id=1115661 andhttps://bugs.webkit.org/show_bug.cgi?id=215461

@domenic I found that the Chrome failures are something to do with WPT or WebDriver or whatever, as the results are different between a normal Chrome instance and the instance started bywpt run.

A normal instance:

python wpt run --binary "C:/Program Files (x86)/Google/Chrome/Application/chrome.exe" chrome dom/events/Event-dispatch-click.html:

I'd like to merge this and file a relevant Chromium bug, does that sound good?

Yes, that's great; thanks! Please leave a comment here when you do file the bug and I can help get it triaged.

BTW, not sure how to add tests for physical mouse clicks as#2368 (comment) is a blocker. Sinceonclick on input won't work I thought I would add onclick for the parent element, but it does not bubble at all on Gecko 🤷‍♀️

What does the spec say about it today?

Hmm, but later in that thread in#2368 (comment) it looked like Gecko changed their behavior.

The spec says that physical mouse clicks on disabled elements should not trigger any events. So I was thinking a test that does something likeawait test_driver.click(element); assert_equals(element.checked, false).

However now that I write that out, it seems kind of obvious that it will pass. It's such a basic feature of disabling form controls that users clicking on them won't change them; writing a test isn't very necessary. I guess I lost sight of that.

The spec says that physical mouse clicks on disabled elements should not trigger any events.

Does it mean the parent should not get any bubbled events either? Currently it does get one on Chrome, should I file a bug?

The exact wording is

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.

which indicates to me that it is OK to dispatch to the parent. It's not very precise though. But I think full interop here is waiting on a "hit testing" specification, which determines how to translate raw OS mouse clicks into DOM events and takes into account all sorts of things like disabledness, CSS boxes (including rounded corners, etc.), CSS transforms, and the like. Not an easy job.

Filedhttps://bugs.chromium.org/p/chromium/issues/detail?id=1116161 for the failures.

Thanks for the spec and testing work here. I'll take a look at the Chromium implementation.