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

Pointer events & disabled form elements #177

Closed
jakearchibald opened this Issue Feb 17, 2017 · 27 comments

Comments

Projects
None yet
@jakearchibald
Copy link

jakearchibald commented Feb 17, 2017

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

Neither Edge or Chrome fire pointer events when the mouse is over disabled form controls. This isn't the form control preventing propagation - it also prevents capturing listeners at the window level.

This seems to be mirroring mouse events, but this behaviour isn't in the spec (and isn't how Firefox behaves), and appears to be legacy.

Given that pointer events are somewhat of a clean break, shouldn't this behaviour be changed, or at least specced?

setPointerCapture can be used to work around it if the pointerdown happens elsewhere.

@RByers

This comment has been minimized.

Copy link
Contributor

RByers commented Feb 23, 2017

Wow, this is crazy - I was not aware of it. Jake's blog post does a good job articulating why this is bad (breaks some drag and drop scenarios). @tkent-google @garykac @dtapuska @mustaqahmed @patrickkettner @smaug---- WDYT?

Unless we can find some compelling reason why this weird behavior is important, IMHO we should just try removing it from blink (for pointer and mouse events). If that causes non-trivial breakage than we can fall back to adding in (and speccing) a mouse-event-specific hack while leaving pointer events intact. But given that Firefox doesn't have this weird behavior, I suspect we can get away with just eliminating it entirely.

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Feb 23, 2017

I agree this is a wart. I've looked at the chromium code and I don't fully understand where this is coming from. I see some special code around not activating the active css state for disabled form controls on mouse move. But will need to debug.

@smaug----

This comment has been minimized.

Copy link
Contributor

smaug---- commented Feb 23, 2017

Hmm, I wonder which crazy behavior we're talking about there, since Gecko certainly has rather ad-hoc crazy behavior. It used to be even crazier.
http://searchfox.org/mozilla-central/rev/b1044cf7c2000c3e75e8181e893236a940c8b6d2/dom/html/nsGenericHTMLElement.cpp#2264

@mustaqahmed

This comment has been minimized.

Copy link
Contributor

mustaqahmed commented Feb 23, 2017

Chromium drops mouse events for disabled form controls here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Node.cpp?rcl=cb12cafde748de82eb55f491054eb2cd84fed63c&l=2075
Not sure why PointerEvents are also affected.

@tkent-google

This comment has been minimized.

Copy link

tkent-google commented Feb 24, 2017

This disabled behavior is a source of some bugs in Chromium. I'd like to remove it if possible.

@scottgonzalez

This comment has been minimized.

Copy link
Member

scottgonzalez commented Feb 24, 2017

I recall this behavior causing bugs in jQuery UI as well. I'd like to see it go away.

@garykac

This comment has been minimized.

Copy link
Member

garykac commented Feb 24, 2017

+1 to making things sane

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Feb 24, 2017

So FireFox doesn't fire pointerdown and pointerup but does fire pointermove. What should Chrome do?

I found the code that makes pointer events not be dispatched to disabled form controls. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/events/PointerEvent.cpp?q=PointerEvent.cpp&l=86

I've removed the line locally and all is well. We do send pointerdown, and pointerup. I presume we should in a sane model right?

@domenic

This comment has been minimized.

Copy link

domenic commented Feb 24, 2017

It seems definitely bad to fire click events. It seems definitely good to fire (mouse/pointer)move events. I don't know what should be done about (mouse/pointer)(up/down) events.

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Feb 24, 2017

Chromium issue filed here

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Feb 24, 2017

I'd like to treat pointer and mouse as completely separate issues. I don't want to make the waters murky by making both decisions/changes together.

@domenic

This comment has been minimized.

Copy link

domenic commented Feb 24, 2017

That seems really bad for a rational, predictable platform :(

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Feb 24, 2017

I think the interop issues for pointerevents will be non-existent. But perhaps there are interop issues that might be difficult to do this for mouse events. But from a rationality point of view I think we should make the change without prejudice for pointer events; mouse events requires more investigation/experimentation.

@jakearchibald

This comment has been minimized.

Copy link

jakearchibald commented Feb 24, 2017

The "up" event is important for drag&drop. You need to know when the drag ends.

@dmethvin

This comment has been minimized.

Copy link

dmethvin commented Feb 25, 2017

The pointerover and mouseover events are also important for things like tooltips where you'd like to notify someone why a button is disabled. jQuery has received complaints about this behavior for years.

https://bugs.jquery.com/ticket/7359

We actually removed some of the restrictions we had on delegated events, which gives inconsistent cross-browser results but at least lets it work right in some browsers.

https://bugs.jquery.com/ticket/11764

I doubt there would be big compat impacts by allowing mouse-related events other than click, especially considering how many people have seemed to want the behavior over the years.

@dtapuska

This comment has been minimized.

@smaug----

This comment has been minimized.

Copy link
Contributor

smaug---- commented Feb 27, 2017

Hmm, well, it isn't even agreed how pointer events and disabled form elements should work.
Do we want to allow all the pointer events or everything else but down/up?

@dtapuska

This comment has been minimized.

Copy link

dtapuska commented Feb 27, 2017

This spec issue is still open. We have to collectively decide what we want to do. Chrome's model closer matches FireFox's model for pointer events (it now fires pointermove, pointerout, pointerover, pointerenter, pointerleave). But chrome does fire pointerup and pointerdown which FireFox does not.

@RByers

This comment has been minimized.

Copy link
Contributor

RByers commented Feb 27, 2017

@smaug---- do you have a reason why we wouldn't want to fire pointerdown and pointerup? Certainly consistency between mouse and pointer events is one argument. But is there any reason (other than annoying web compat legacy) why disabled form controls should swallow mousedown and mouseup?

It looks like Firefox also suppresses touchstart and touchend on disabled form controls where Chrome does not (trying to test Safari now but my iPhone is not cooporating). Depending on the conclusion we reach here, we may want to file a TouchEvents-specific spec issue as well.

@smaug----

This comment has been minimized.

Copy link
Contributor

smaug---- commented Feb 27, 2017

Mainly because of backwards compatibility with mouse event handling.

@RByers

This comment has been minimized.

Copy link
Contributor

RByers commented Feb 28, 2017

I verified Safari fires touch events on disabled form controls, so Gecko's deviation there definitely seems like a bug to me.

If the only concern is web compat, then it seems to me like Pointer Events is the best chance we'll ever get to fix this and we should at least try. It seems unlikely that sites will depend on the pointer and mouse events matching perfectly (code will typically pay attention to one or the other, not both). I suppose it's possible (even likely) that when updating a site to use Pointer Events, the existing code could be surprised to receive events from disabled form controls. But to me it seems worth the cost/risk to try to fix this. @smaug---- do you disagree? What's the alternative for solving the issues Jake, Scott and Dave mention above?

@patrickkettner can you check whether the Edge behavior here was intentional for some reason, or just a carry-over form how mouse events already behaved? Would you consider removing it if Chrome ships our fix to stable successfully?

@jakearchibald

This comment has been minimized.

Copy link

jakearchibald commented Feb 28, 2017

I don't see why we'd want compatibility with mouse events here given they're weird, and Firefox does something different (well, better) anyway.

We should always fire pointer-based events regardless of element, it should be the developer's decision how to react to it. Why shouldn't I be able to drag & drop a disabled button?

The click event is different, as it's related to "activation" rather than a pointer, so it makes sense that the element's state is taken into consideration. But even then I'd rather it was explained within the event system. As in, a disabled element could stopImmediatePropagation in the bubbling phase of a click event, meaning developers could still use the capturing phase if they wanted clicks.

@smaug----

This comment has been minimized.

Copy link
Contributor

smaug---- commented Feb 28, 2017

There is the bug about possibly making click a pointer event. click must not do anything with disabled form elements (that sure would regress stuff). #100
Even just having capture phase for click sounds very regression risky.

But for pointerdown/up... I guess we can try to have normal event dispatch for those.

@OliverJAsh

This comment has been minimized.

Copy link

OliverJAsh commented Mar 9, 2017

Hey. After reading Jake's blog post I found some more weird behaviour to add to the confusion:

Child elements of disabled buttons (and perhaps other disabled elements) do receive mouse events (only tested in Chrome). Demo: http://jsbin.com/zufotac/2/edit?html,js,console,output

@smaug----

This comment has been minimized.

Copy link
Contributor

smaug---- commented Mar 14, 2017

Related to this is also audio/video handling. https://html.spec.whatwg.org/#user-interface vaguely says that some events (but which?) should be suppressed. Blink at least eats some of the events when on top of video.

@NavidZ NavidZ self-assigned this Mar 21, 2018

@NavidZ

This comment has been minimized.

Copy link
Member

NavidZ commented Mar 21, 2018

We talked about this in the call and we agreed to have a test to expect pointerevents (down, up, move) but no click.

@NavidZ

This comment has been minimized.

Copy link
Member

NavidZ commented Mar 29, 2018

The test is recently added for this here. We need to update the w3c/test-results though to include the result for multiple vendors as well.

@NavidZ NavidZ closed this Mar 29, 2018

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