Mouse events & disabled form controls

[jakearchibald]

Test: http://jsbin.com/botohet/edit?js,output

https://html.spec.whatwg.org/multipage/forms.html#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 guess this is weird legacy behaviour, as it completely prevents the event, rather than stopping propagation during the bubbling phase.

Currently Chrome, Edge & Safari apply the same behaviour to all mouse events. I'd much prefer that all browsers switched Firefox's behaviour, but if it's too late to do this, the weird behaviour should probably become part of the spec.

Unfortunately Chrome & Edge do the same for pointer events, but hopefully that can be changed w3c/pointerevents#177. This was fixed for pointer events.

[annevk]

Someone needs to define "hit testing" basically. That's the root of all these issues.

[tabatkins]

??? Hit-testing is clearly working correctly here - it correctly hit-tests that you're over a disabled form control, and then swallows the mouse event. That's the issue here.

[annevk]

Yeah, I got this confused with defining mouse events, which need hit testing to be properly defined (hit testing would tell them it's a disabled control, at which point they wouldn't dispatch the mouse event, but maybe would dispatch the pointer event in the same task).

[jakearchibald]

@RByers @jacobrossi any insight into where this weird behaviour comes from?

[RByers]

Wow, this is news to me! Since the main thing you're talking about isn't actually defined by HTML, let's discuss over in w3c/pointerevents#177. Once we figure that out, let's come back to the click behavior defined by HTML - maybe we can eliminate that oddity too?

[bzbarsky]

Note that the issue description here is not quite right about what the "firefox behavior" is or the other browsers' behavior, afaict. See https://lists.w3.org/Archives/Public/public-html/2015Oct/0010.html

[rniwa]

It looks like Gecko basically stops preventing the dispatching of all events on disabled form controls while WebKit and Blink seem to simply ignore event listeners on disabled form controls.

See https://gist.github.com/rniwa/bf0f1411d6b811fcb605e796498740f3

Gecko yields nothing while WebKit and Blink yields:

click on div
test on button
test on div

[rniwa]

I updated my test case a bit (updated the gist). It looks like Gecko is simply truncating the event path at the first disabled form control. This behavior is saner than WebKit/Blink's.

I do have a mild concern that preventing all events from being dispatched on a disabled form control might be a breaking change for some websites. Given WebKit/Blink only has this quirk for MouseEvent, that might be good enough.

I'd also add that while WebKit/Blink behavior is very odd, it probably has the least effect to the rest of the event dispatching behavior so it might be something to consider.

[jakearchibald]

Blink has since changed behaviour for mouse events. http://output.jsbin.com/botohet/quiet - the listener here is on the window object (capturing phase). You get mouse/down/up events on the disabled button in Blink, whereas you don't in WebKit.

[rniwa]

You mean pointer events? I don't see any mousemove or mousedown on Chrome 71.0.3544.2

[jakearchibald]

I'm getting both mouse & pointer events in 68 and 71.

[jakearchibald]

@rniwa apologies. It only fires mouse events with the "Experimental web platform" flag.

[TimothyGu]

It's 2019. With https://jsbin.com/cafidayeri/1/edit?html,js,console,output, Firefox seems to allow any synthetic events to be fired on the element itself, except click events coming from the browser – precisely the spec behavior. On the other hand, Chrome prevents any MouseEvent from firing on the element itself. This includes not just click events, but also mousemove events, either synthetic or coming from the browser.

Both browsers prevent click() from doing anything if a button is disabled.

Relevant WPT: https://github.com/web-platform-tests/wpt/blob/master/html/semantics/forms/attributes-common-to-form-controls/disabled-elements-01.html. This checks that synthetic non-MouseEvent event goes through, which seems to be just about the only thing the two browsers agree on.

kind	click MouseEvent	mousemove MouseEvent	click Event	mousemove Event	click()
synthetic	Chrome no, FF yes, spec yes	Chrome no, FF yes, spec yes	Chrome yes, FF yes, spec ambiguous-to-yes*; WPT-tested	all yes	all no
natural	all no	Chrome no, FF yes, spec yes

*: spec says “click events”; it’s unclear whether this involves checking if the event is an MouseEvent object or not, though I’m inclined to say yes it does as that’s what Chrome and FF agree on.

[domenic]

For the record, @eps1lon ran into this, and @brendo tried to fix it, in jsdom: jsdom/jsdom#2665 and jsdom/jsdom#2681. This is quite the interop footgun...

The test case there was very simple: just someDisabledButtonElement.dispatchEvent(new MouseEvent('click')). That will trigger any click listeners in Firefox, and not in Chrome. (I can't test WebKit right now.) I guess reading the above thread though, the mess is much bigger than that.

Oh wow, @TimothyGu posted a much larger analysis while I was writing this, I see :).

/cc @tkent-google since I know he likes interop bugs and form controls.

[saschanaz]

That will trigger any click listeners in Firefox, and not in Chrome. (I can't test WebKit right now.)

Based on what I tested on #5000, WebKit does not trigger click listeners. (But interestingly mutates checkboxes!)

[eps1lon]

I want to share a case related to focus events.

If you have a non-focusable element e.g. <div /> you can div.dispatchEvent(new FocusEvent('focus')) and any focus event listener on the div will be executed. On the other hand calling div.focus() will not dispatch any event.

Dispatching click events on a disabled button will not execute click handlers on that button in Chrome. It will also not dispatch click events when calling button.click()

A div without a tabIndex acts with regard to focus like a disabled button acts with regard to click.

IMO I'd prefer to not prevent synthetic events. While this is a somewhat common footgun when writing tests I would always recommend using an imperative method if it exists rather than dispatching synthetic events.

[jgraham]

Firefox now seems to be shipping 2 different site patches to work around sites which depend on the Blink/WebKit behaviour here (c.f. bug 1653882). To me it seems hard to justify any course of action other than aligning the spec with the majority of implementations and updating Gecko to match.

[josepharhar]

BTW, having this and #5886 together really doesn't help, can we close either one?

This one is for allowing more MouseEvents on disabled form controls, and that one is for the bubbling behavior on disabled form controls. I don't have strong feelings about keeping the other one open so if it helps you then please close it, but the separation is clear in my head.

[saschanaz]

Hmm, could be good to change the title for this issue, but I don't have permission for that. (The current title sounds like it covers all issues regarding to mouse events and disabled form controls, and also the OP mentions bubbling...)

[saschanaz]

https://wpt.fyi/results/html/semantics/disabled-elements/disabled-event-dispatch-additional.tentative.html?label=master&label=experimental&aligned The -additional test somehow expect different behavior between dblclick and auxclick, should they be consistent?

[josepharhar]

I added auxclick to that test just to test the behavior at the request of my code reviewer.
I see that safari and firefox both are blocking auxclick events, but we never discussed blocking them in addition to the list of events we have explicitly discussed blocking, which currently includes click, mouseup, mousedown, and dblclick.
Is it true that auxclick events are also being blocked on disabled form control elements in firefox/safari? Is there a reason? Are there additional events that I'm not aware of that we need to consider?

[saschanaz]

Gecko doesn't fire contextmenu either, although it's an allowlist instead of denylist in Gecko, so anything not in that list is blocked. (See #2368 (comment))

I have no strong opinion, I don't think contextmenu and auxclick is about activation, so I don't see any reason to block them.

[harelyshau]

Not sure that my point is related to this topic, but I found this behaviour:

Event "dblclick" and "contextmenu" are fired for disabled button in Google Chrome.
In Edge only "contextmenu" is fired for disabled button.
On Firefox no one of above are fired.
On Safari I faced with strange behaviour: seems these events are not fired for disabled button. But there is a case when both of them are fired (https://harelyshau.dev/#/minesweeper). Don't understand the difference.

All tests on MacOS.
With following example:
<button onclick="console.log('left click')" oncontextmenu="event.preventDefault(); console.log('right click')" ondblclick="console.log('double click')" disabled />

[DzmVasileusky]

Are there any simple workarounds for mouseenter besides handling events on the disabled control wrapper?
There is a pretty legit case for it like showing a hint explaining why a form control is disabled.

[scottaohara]

displaying a hint, via tooltip, to describe why a control is disabled is something people are doing - but it's an antipattern that doesn't account for the fact that if the control is disabled, then someone using keyboard wont' be able to focus the control / reveal this tooltip.

Unfortunately, the only workaround I would suggest is a design that is more inclusive, and doesnt' assume that all users can hover over the disabled control.

[josepharhar]

Event "dblclick" and "contextmenu" are fired for disabled button in Google Chrome.
In Edge only "contextmenu" is fired for disabled button.

dblclick is blocked in chromium, which includes chrome and edge. I implemented this due to feedback in this thread: #2368 (comment)

Are there any simple workarounds for mouseenter besides handling events on the disabled control wrapper?

mouseenter should work on disabled form controls. it is fired in chrome based on my testing: https://jsfiddle.net/jarhar/652yamct/4/

Unfortunately, the only workaround I would suggest is a design that is more inclusive, and doesnt' assume that all users can hover over the disabled control.

+1 to making websites accessible