Reach-ui: [Tooltip] Use Pointer Events

[raunofreiberg]

🚀 Feature request

Current Behavior

Using @reach/tooltip with disabled buttons is not possible. See: #231

This is not specific to Reach UI, but rather a browser implementation detail, which can't be worked around without adding an additional wrapper around disabled buttons (which also has styling implications and is generally unpredictable).

Desired Behavior

Using @reach/tooltip with disabled buttons would be _somewhat_ possible.

Suggested Solution

I have experimented with using Pointer Events (not to be mistaken with CSS pointer-events property) and they seem to produce desired results.

More specifically, onPointerEnter and onPointerLeave seem to both be fired on disabled buttons. An example: https://codesandbox.io/s/gracious-galileo-qymqw?file=/src/App.js

I don't know what other implications this may have, or why do these events fire on disabled buttons, but it might be worth considering using said events instead of onMouseEnter/onMouseLeave, especially since onMouseEnter should not fire on disabled inputs as of React 16.13.0

Who does this impact? Who is this for?

All users of Tooltip.

Describe alternatives you've considered

I know this can be done in user land with the useTooltip hook by mapping the mouse events to pointer events, and I'm not expecting Reach UI to do anything here — but I thought it would be something interesting to consider. I think it would be really cool to support disabled buttons out of the box (which is a surprisingly common use case).

[chaance]

Interesting, thanks for bringing this up. Have you tested this on touch by chance? I'm a little concerned about pointerenter:

The pointerenter event fires when a pointing device is moved into the hit test boundaries of an element or one of its descendants, including as a result of a pointerdown event from a device that does not support hover.

I'm not sure if we want tooltips showing up on touch events. I think some stylus inputs have a detectable hover range, but for those that don't we'd probably need to account for that. I'm open to a PR that uses pointer events only when supported and falls back to mouse events, but I'd also want it to be tested well on touch devices. I can't promise I'll have time to deal with them myself right away, but I'm happy to help test if you want to get it started!

[raunofreiberg]

Interesting, thanks for bringing this up. Have you tested this on touch by chance? I'm a little concerned about pointerenter:

Hmm, yes. You are correct. I tested this on an iPhone XS on Safari and the example above does indeed seem to respond to a pointerdown event: https://streamable.com/gjthl7

This may not be what we want.

[raunofreiberg]

It is possible to distinguish pointer types, so we could disable this for touch/pen events: https://developers.google.com/web/updates/2016/10/pointer-events#different_input_types

[raunofreiberg]

Digging further, the reason why Mouse Events don't work on disabled elements is a misinterpretation of the spec:

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.

Source: https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#enabling-and-disabling-form-controls:-the-disabled-attribute

---

The spec states that only click events should be prevented, but browsers seem to prevent _all_ mouse events. Couldn't the browser just send events on disabled elements and let the developer take care of them?

Yep.

Pointer Events has addressed this problem by following the spec more closely and deliberately sending events on disabled elements.

Context:

• Pointer Events issue (resolved): https://github.com/w3c/pointerevents/issues/177
• Pointer Events Chromium issue (resolved): https://codereview.chromium.org/2716063002/
• Mouse Events issue (unresolved): https://github.com/whatwg/html/issues/2368