Pointer events & disabled form elements

[jakearchibald]

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]

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]

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

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]

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 disabled behavior is a source of some bugs in Chromium. I'd like to remove it if possible.

[scottgonzalez]

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

[garykac]

+1 to making things sane

[dtapuska]

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]

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]

Chromium issue filed here

[dtapuska]

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]

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

[dtapuska]

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]

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

[dmethvin]

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]

@jakearchibald Fix in chrome https://codereview.chromium.org/2716063002/

[smaug----]

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

@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----]

Mainly because of backwards compatibility with mouse event handling.

[RByers]

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]

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

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]

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

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]

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

[NavidZ]

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.