facebook / react

The library for web and native user interfaces.
https://react.dev
MIT License
229.33k stars 46.96k forks source link

Mouseenter event not triggered when cursor moves from disabled button #10109

Open stepancar opened 7 years ago

stepancar commented 7 years ago

BUG.

Mouseenter event not triggered when cursor moves from disabled button see [example](https://alfa-laboratory.github.io/arui-feather/styleguide/#playground/code=%3Cdiv%3E%0A%20%0A%20%20%20%20%3Cdiv%20className='row'%3E%0A%20%20%20%20%20%20%20%20Hover%20on%20%20right%20button%20and%20then%20move%20cursor%20to%20left%20button%0A%20%20%20%20%20%20%20%20%3Cdiv%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Cbutton%20onMouseEnter=%7B()=%3E%7Balert('Hey!');%7D%7D%20%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20Not%20Disabled%0A%20%20%20%20%20%20%20%20%20%20%20%20%3C/button%3E%0A%20%20%20%20%20%20%20%20%3C/div%3E%0A%20%20%20%20%20%20%20%20%3Cdiv%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Cbutton%20disabled=%7B%20true%20%7D%3EDisabled%3C/button%3E%0A%20%20%20%20%20%20%20%20%3C/div%3E%0A%20%20%20%20%3C/div%3E%0A%0A%20%20%20%20%3Cdiv%20className='row'%3E%0A%20%20%20%20%20%20%20%20Hover%20on%20%20right%20button%20and%20then%20move%20cursor%20to%20left%20button%0A%20%20%20%20%20%20%20%20%3Cdiv%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Cbutton%20onMouseEnter=%7B()=%3E%7Balert('Hey!');%7D%7D%20%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20Not%20Disabled%0A%20%20%20%20%20%20%20%20%20%20%20%20%3C/button%3E%0A%20%20%20%20%20%20%20%20%3C/div%3E%0A%20%20%20%20%20%20%20%20%3Cdiv%3E%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Cbutton%3ENot%20Disabled%3C/button%3E%0A%20%20%20%20%20%20%20%20%3C/div%3E%0A%20%20%20%20%3C/div%3E%0A%20%0A%3C/div%3E)

What is the expected behavior? Should trigger Mouseenter event

React 15.5.3 Latest Chrome MacOs 10.12.5

Andarist commented 7 years ago

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 commented 7 years ago

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

Andarist commented 7 years ago

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 commented 7 years ago

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

aweary commented 7 years ago

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

jquense commented 7 years ago

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 commented 7 years ago

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 commented 6 years ago

@jquense Does the fix in https://github.com/facebook/react/pull/10149 make sense to you?

Justin-ZS commented 6 years ago

Same problem here😞.(react@16.3.2)

padraigfl commented 5 years ago

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 commented 4 years ago

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:

Screenshot 2020-04-20 at 00 00 19

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 commented 4 years ago

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 commented 3 years ago

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: Screen Shot 2020-12-02 at 5 33 32 PM side note, it appears fixed in react 17

vlazh commented 2 years ago

It's still not fixed in 17.0.2 - example

benhall847 commented 1 year ago

I can also confirm this is still not fixed