Allow mutating <input disabled type=checkbox/radio>

[saschanaz]

Closes #5000

• At least two implementers are interested (and none opposed): This change describes existing behaviors.
  • Firefox (@annevk could you double check?)
  • Chrome input[type=checkbox] is mutable even when disabled on every browser #5000 (comment)
• Tests are written and can be reviewed and commented upon at:
  • Add tests for disabled input clicks web-platform-tests/wpt#24975
• Implementation bugs are filed:
  • Chrome: …
  • Firefox: ...
  • Safari: …

(See WHATWG Working Mode: Changes for more details.)

---

/input.html ( diff )

[domenic]

Looks great with nits, thank you!

Would you also be willing to work on web platform tests? That should also help clarify the implementer-interest situation; if 2+ browsers pass them then we can merge straightaway.

[saschanaz]

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.

[domenic]

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.

[domenic]

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 by https://html.spec.whatwg.org/#enabling-and-disabling-form-controls:-the-disabled-attribute

Not yet tested in web-platform-tests/wpt#24975.

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

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

Tested in web-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 from web-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 in web-platform-tests/wpt#24975.

[saschanaz]

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.

[saschanaz]

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

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

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

[domenic]

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

[domenic]

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.

[saschanaz]

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:

var input = document.createElement("input");
input.type = "checkbox";
input.disabled = true;
input.dispatchEvent(new MouseEvent("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: Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1115661 and https://bugs.webkit.org/show_bug.cgi?id=215461

[saschanaz]

@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 by wpt 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?

[domenic]

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

[saschanaz]

BTW, not sure how to add tests for physical mouse clicks as #2368 (comment) is a blocker. Since onclick 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?

[domenic]

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 like await 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.

[saschanaz]

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?

[domenic]

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.

[saschanaz]

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

[saschanaz]

Taking a late second look, and this specific change now looks redundant as they are now always mutable per the first change anyway. What do you think? @domenic

[saschanaz]

Or maybe we can keep this and revert the first change because disabled checkboxes are not user-mutable. (And AFAICT "mutable" is defined as being mutable via user interface)

[domenic]

Oh, good point, yes, we should keep this and revert the first change. Thank you for double-checking.

[domenic]

Hmm, although mutability also impacts legacy-pre-activation behavior and legacy-canceled-activation behavior. So maybe we need to add checks there too?

[saschanaz]

Those behaviors only apply for radio/checkboxes so maybe the mutability check can be removed.

[domenic]

Oh, great point, yes, I think they can be removed.

[mfreed7]

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