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 · 12 comments

Comments

7 participants
@jakearchibald
Copy link
Collaborator

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.

@annevk

This comment has been minimized.

Copy link
Member

annevk commented Feb 17, 2017

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

@tabatkins

This comment has been minimized.

Copy link
Collaborator

tabatkins commented Feb 17, 2017

??? 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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Feb 20, 2017

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

@RByers

This comment has been minimized.

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

This comment has been minimized.

Copy link
Collaborator

bzbarsky commented Mar 16, 2017

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link
Collaborator

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

This comment has been minimized.

Copy link
Collaborator

rniwa commented Sep 6, 2018

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

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Sep 6, 2018

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

@jakearchibald

This comment has been minimized.

Copy link
Collaborator

jakearchibald commented Sep 6, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment