Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mouse events & disabled form controls #2368

Open
jakearchibald opened this issue Feb 17, 2017 · 43 comments
Open

Mouse events & disabled form controls #2368

jakearchibald opened this issue Feb 17, 2017 · 43 comments
Labels
interop Implementations are not interoperable with each other topic: events topic: forms

Comments

@jakearchibald
Copy link
Contributor

jakearchibald commented Feb 17, 2017

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
Copy link
Member

annevk commented Feb 17, 2017

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

@tabatkins
Copy link
Contributor

??? 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
Copy link
Member

annevk commented Feb 18, 2017

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
Copy link
Contributor Author

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

@RByers
Copy link

RByers commented Feb 23, 2017

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
Copy link
Contributor

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
Copy link

rniwa commented Sep 6, 2018

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
Copy link

rniwa commented Sep 6, 2018

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
Copy link
Contributor Author

jakearchibald commented Sep 6, 2018

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
Copy link

rniwa commented Sep 6, 2018

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

@jakearchibald
Copy link
Contributor Author

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

@jakearchibald
Copy link
Contributor Author

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

@TimothyGu
Copy link
Member

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
Copy link
Member

domenic commented Oct 14, 2019

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
Copy link
Member

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!)

@domenic domenic added the interop Implementations are not interoperable with each other label Oct 14, 2019
@eps1lon
Copy link

eps1lon commented Oct 14, 2019

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
Copy link
Member

jgraham commented Jun 23, 2021

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
Copy link
Contributor

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
Copy link
Member

saschanaz commented Nov 3, 2023

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...)

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 9, 2023
As discussed here, we should apply the event blocking behavior for
disablerd form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 9, 2023
As discussed here, we should apply the event blocking behavior for
disablerd form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 10, 2023
As discussed here, we should apply the event blocking behavior for
disablerd form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 16, 2023
As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
aarongable pushed a commit to chromium/chromium that referenced this issue Nov 17, 2023
As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225838}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 17, 2023
As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225838}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Nov 17, 2023
As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225838}
webkit-commit-queue pushed a commit to Ahmad-S792/WebKit that referenced this issue Nov 19, 2023
https://bugs.webkit.org/show_bug.cgi?id=265071
rdar://problem/118584431

Reviewed by Tim Nguyen.

This patch extends to not fire double click events on disabled elements similar to click event aligning with
Gecko / Firefox, Blink / Chromium and agreed behavior in web specification issue [1]:

[1] whatwg/html#2368 (comment)

* Source/WebCore/dom/EventDispatcher.cpp:
(EventDispatcher::dispatchEvent):
* LayoutTests/imported/w3c/web-platform-tests/html/semantics/disabled-elements/disabled-event-dispatch.tentative-expected.txt: Rebaselined
* LayoutTests/platform/ios-simulator-16-wk2/imported/w3c/web-platform-tests/html/semantics/disabled-elements/disabled-event-dispatch.tentative-expected.txt: Rebaselined
* LayoutTests/platform/ios/imported/w3c/web-platform-tests/html/semantics/disabled-elements/disabled-event-dispatch.tentative-expected.txt: Rebaselined

Canonical link: https://commits.webkit.org/270951@main
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 22, 2023
…trol elements, a=testonly

Automatic update from web-platform-tests
Don't fire dblclick on disabled form control elements

As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225838}

--

wpt-commits: dd5d55c3debd577a09921b32f3816797664c5e86
wpt-pr: 42976
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 22, 2023
…trol elements, a=testonly

Automatic update from web-platform-tests
Don't fire dblclick on disabled form control elements

As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225838}

--

wpt-commits: dd5d55c3debd577a09921b32f3816797664c5e86
wpt-pr: 42976
vinnydiehl pushed a commit to vinnydiehl/mozilla-unified that referenced this issue Nov 24, 2023
…trol elements, a=testonly

Automatic update from web-platform-tests
Don't fire dblclick on disabled form control elements

As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225838}

--

wpt-commits: dd5d55c3debd577a09921b32f3816797664c5e86
wpt-pr: 42976
vinnydiehl pushed a commit to vinnydiehl/mozilla-unified that referenced this issue Nov 24, 2023
…trol elements, a=testonly

Automatic update from web-platform-tests
Don't fire dblclick on disabled form control elements

As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <[email protected]>
Reviewed-by: Mason Freed <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1225838}

--

wpt-commits: dd5d55c3debd577a09921b32f3816797664c5e86
wpt-pr: 42976
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Nov 30, 2023
…trol elements, a=testonly

Automatic update from web-platform-tests
Don't fire dblclick on disabled form control elements

As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <jarharchromium.org>
Reviewed-by: Mason Freed <masonfchromium.org>
Cr-Commit-Position: refs/heads/main{#1225838}

--

wpt-commits: dd5d55c3debd577a09921b32f3816797664c5e86
wpt-pr: 42976

UltraBlame original commit: 3bf4c6228d9c37fc63955610b37cb0bf6d5dff3d
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Nov 30, 2023
…trol elements, a=testonly

Automatic update from web-platform-tests
Don't fire dblclick on disabled form control elements

As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <jarharchromium.org>
Reviewed-by: Mason Freed <masonfchromium.org>
Cr-Commit-Position: refs/heads/main{#1225838}

--

wpt-commits: dd5d55c3debd577a09921b32f3816797664c5e86
wpt-pr: 42976

UltraBlame original commit: 3bf4c6228d9c37fc63955610b37cb0bf6d5dff3d
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Nov 30, 2023
…trol elements, a=testonly

Automatic update from web-platform-tests
Don't fire dblclick on disabled form control elements

As discussed here, we should apply the event blocking behavior for
disabled form controls to dblclick in addition to click, mouseup, and
mousedown:
whatwg/html#2368 (comment)

Change-Id: Ibc52585ce0704d8ba8467efc3462bd378d23fbae
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5007308
Commit-Queue: Joey Arhar <jarharchromium.org>
Reviewed-by: Mason Freed <masonfchromium.org>
Cr-Commit-Position: refs/heads/main{#1225838}

--

wpt-commits: dd5d55c3debd577a09921b32f3816797664c5e86
wpt-pr: 42976

UltraBlame original commit: 3bf4c6228d9c37fc63955610b37cb0bf6d5dff3d
@saschanaz
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link

harelyshau commented Feb 4, 2024

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
Copy link

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
Copy link
Collaborator

scottaohara commented May 1, 2024

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interop Implementations are not interoperable with each other topic: events topic: forms
Development

No branches or pull requests