Make react-juce onMouseEnter and onMouseLeave events behave like their web counterparts

[androidStern]

The Problem

react-juce mouseEnter and mouseLeave events don't behave like their web counterparts

Background

Juce's mouseEnter and mouseExit events differ from their browser counterparts in a few ways (detailed below). Because react-juce simply forwards Juce mouse events onto the javascript engine, the react environment has inherited Juce's behavior which is unintuitive for react developers. So, the goal here is to make the behavior in react-juce components conform to the web behaviors as much as possible.

Behavior Differences

1. When moving from a parent to a child element
   • Juce (and by extension, react-juce) will fire a mouseLeave on the Parent and a mouseEnter on the Child
   • Browsers will only fire a mouseEnter on the Child
2. When moving from a child to it's parent
   • Juce will fire a mouse leave on the Child and a mouseEnter on it's Parent
   • Browsers will only fire a mouseLeave on the child
3. When entering an exiting elements while holding the mouse button down
   • Juce will not fire any enter or exit events
   • Browsers will fire both events as described above
4. mouseEnter and mouseLeave events dont bubble in browser but do in current react-juce

TLDR for points 1 & 2: From the browser's perspective, the mouse is still inside an element if it is inside any of its children and mouse buttons have no effect.

Extra Stuff

To get a feel for how these events behave in the browser you can check out this page.

See this discord thread for additional context

Finally, I haven't researched what the expected behavior is when the DOM hierarchy changes while the mouse is moving but that's something to consider as well.

[nick-thompson]

Excellent report @androidStern thank you.

I'm thinking that 1 & 2 we can do our own small check right here to say "if we're leaving but the place we're leaving to is a child component, don't fire the event" and similar for the other direction.

I think (3) will probably be a game of just finding and implementing other details of the juce::Component spec.

And (4), great catch, we can filter which types of events get bubbled right here.

I'm going to leave this one here and mark it as a good first issue for a new contributor, this is a great way to dip your toes into the project

[androidStern]

Regarding # 3: I'm not aware of any juce::component features that will solve this mousebutton problem. Some members of the juce discord forum suggested using DragAndDropContainer and DADTarget since they provide a dragEnter and dragExit callback that fire when mouse is held down and enter occurs. Imo, co-opting D&DContainer is icky and brings its own set of unwanted behaviors. DragAndDropContainer code just handles drag events at a parent component and manually dispatches enter and exit events to the appropriate children which isnt complicated to do ourselves. Still on the lookout for a native juce solution though.

[androidStern]

Regarding # 2: The tricky bit is disambiguating mouseEnters caused by moving from a child out to its parent (we want to stifle these) and mouseEnters caused by moving from parent into its child (we these to fire on the child). Inside a mouseEnter callback you're saying "which direction am I coming from. there's not enough state on myself or the mouse event to tell me".

So one solution is to add and maintain some state like bool was_really_mouse_over_according_to_browser_spec to each component so they can figure it out in their mouseEnter and mouseExit callbacks. But I don't understand enough about react-juce rendering to know if this works. Are components stable across react renders? If not, I'll lose my mouse state and components are the wrong place to keep it.

[nick-thompson]

Regarding # 3: I'm not aware of any juce::component features that will solve this mousebutton problem. Some members of the juce discord forum suggested using DragAndDropContainer and DADTarget since they provide a dragEnter and dragExit callback that fire when mouse is held down and enter occurs. Imo, co-opting D&DContainer is icky and brings its own set of unwanted behaviors. DragAndDropContainer code just handles drag events at a parent component and manually dispatches enter and exit events to the appropriate children which isnt complicated to do ourselves. Still on the lookout for a native juce solution though.

Yea, I don't feel great about the idea of co-opting the DAD stuff for this, although @JoshMarler and I are planning some drag and drop behavior that sits a DADContainer at the ReactAppRoot level, so in a sense, having View generically inherit from DADTarget is not a major problem. Would need to prove that out and make sure there's no performance impact, but it wouldn't be a crazy lift to do all of this. Still, I really want to believe there's a simpler way to get correct mouseEnter/mouseExit callbacks when the mouse button is down...

Regarding # 2: The tricky bit is disambiguating mouseEnters caused by moving from a child out to its parent (we want to stifle these) and mouseEnters caused by moving from parent into its child (we these to fire on the child). Inside a mouseEnter callback you're saying "which direction am I coming from. there's not enough state on myself or the mouse event to tell me".

Right, I'm wondering if there's a way to, for example, catch the mouseExit event and check if the mouse is now over a child component, in which case we won't push the mouseExit into js. We can do some "check the current position of the mouse" logic here I think, without necessarily needing to maintain any additional state on View. But, I'm taking a bit of a guess here, I definitely haven't worked out the details on that idea ;)

[JoshMarler]

Yeah the mouse button down thing is a pain. @androidStern maybe throw your suggested fix we discussed for #2 here as you could potentially try to leverage the mouseDrag event and workout the Viewinstance under the mouse using the MoustEvent's absolute position. Then during this callback you could potentially try to write/inspect your wasMouseOver flag in some way. I need to think more on this one.

Feels like there should be an easier way to just respond to the MouseInputSource stuff here ...

[androidStern]

@JoshMarler: #238 here's a draft of what we talked about this morning