Mouseenter event not triggered when cursor moves from disabled button

[stepancar]

BUG.

Mouseenter event not triggered when cursor moves from disabled button
see example

What is the expected behavior?
Should trigger Mouseenter event

React 15.5.3
Latest Chrome
MacOs 10.12.5

[Andarist]

I think its because mouseout event is not triggered for disabled form elements, according to https://developer.mozilla.org/en/docs/Web/Events/mouseout and React's synthetic mouseenter event works based on mouseout.

Aint sure if its possible to safely revert detection strategy to the mouseover (which would work), as there is probably some reason why its implemented like that.

[gaearon]

I’ll tag this as a bug, but not sure if it ever worked, or whether it’s possible to fix.

[Andarist]

What can be done about this temporary is to put smth like margin-left: 2px; on the disabled button. (1px doesnt seem to work).

[stepancar]

@gaearon could you check this PR?
Works good for this case

[aweary]

Verified this is still an issue in React 16: https://jsfiddle.net/ut5tqgbk/

[jquense]

Yes this is due to the way the polyfill is implemented and isn't really fixable with the current strategy since it relies on infering the paired event (enter/leave) from the relatedTarget of it's opposite. Just means that since disabled elements don't emit mouseout the entering element won't get a mouseenter

[zikaari]

This is really a big trouble. I tried to get around it by attaching onMouseEnter to li tag wrapping the disabled button. Exhibited same behavior nonetheless 😞

[gaearon]

@jquense Does the fix in #10149 make sense to you?

[padraigfl]

Providing an update. Still seem to be having this issue on the latest versions of react, the mouseEnter event is attached to its direct parent in my case, tried putting it an extra level down (ie the mouse enter event is on the parent's parent) and still had the same issue so I imagine it's catching it but neither acting on it or allowing propagation.

Not a big deal in my case, can work around okay.

[esr360]

I can confirm this is still a bug.

We can see that in native HTML/JS, a non-disabled button will still trigger mouseenter when the previous target is a disabled button: https://codepen.io/esr360/pen/abvmoeJ?editors=1010 - the non-disabled button's background becomes blue, so we know it works.

In React, however, the same behaviour is not seen: https://codesandbox.io/s/throbbing-worker-227tz?file=/src/App.js - when we hover the non-disabled button from the disabled button, onMouseEnter is not called and the background color does not change. If we hover the non-disabled button by any other means, we see the background color change to blue.

From an ex-CSS developer who believes CSS-in-JS is the future, please recognise the importance of fixing bugs like these. I'm building a CSS-in-JS library for React (more of a style-authoring tool), and we can see that even in a very basic example of a carousel with back/next buttons that are adjacent to each other, this issue causes UX/UI impediments that should not be so readily dismissed:

Imagine I click the "Back" button, it becomes disabled, and I then move to click the "Next" button but it doesn't signal the hover state - that will throw me off big time as a user. I do not consider this to be any sort of edge case. This is basic UI/UX.

Thanks for all the hard work from everyone involved.

[mikeyamato]

Just to add some additional fodder, while onMouseEnter is not firing, onMouseLeave is since they traditionally go hand-in-hand. I'd like to use onMouseEnter vs. onMouseOver because it's not sent to any descendants. Super helpful when I have child components that I don't want triggering events.

[snowystinger]

This would be useful when implementing a SpinButton component. When hitting the max or min value, the corresponding button would be disabled. Trying to implement hover state on mouse enter for the opposing direction can be accomplished with mousemove, but it'd make more sense if it worked with mouseenter.
For example:

side note, it appears fixed in react 17

[vlazh]

It's still not fixed in 17.0.2 - example

[benhall847]

I can also confirm this is still not fixed