PopupMenu missing mouseExit

[Archytect]

When we show a PopupMenu after a mouseEnter event, the mouseExit event is ignored. I found the exact issue discussed here :

PopupMenu and mouseExit

Hi! I have a juce::Component subclass which In mouseEnter sets ‘hovered=true’ and repaints differently In mouseExit sets ‘hovered=false’ and repaints differently and this gives me a mouse over hover effect. works great. BUT this component also in monseDown if mods.isPopupMenu() greatest a juce::PopupMenu and does a showMenuAsync on it Clicking on the menu or dismissing the menu never calls the mouseExit on my component. So it stays stuck in hover. I notice Pianotec does the same. Now of c…

I also noticed this issue with all component that display onDesktop, or enterModalState like FileChooser. Currently, I just manually call the mouseExit before the PopupMenu, but seems nasty to me.

Is there a clean fix about it ?

[baconpaul]

Mouseexit before the popup is also “too early”. What we did was add an endhover method to our interfaces and call it from the popup menu async call on exit (being careful that the object lifetime outlasted the menu)

[Archytect]

Yes, true ! This is a better timing to do it. But it’s still tinkering no ? I don’t understand why it’s not fixed in the Juce code

[reuk]

I think the current behaviour is probably incorrect - it’s surprising that mouseEnter/mouseExit calls become unbalanced when displaying a modal component, so JUCE should probably attempt to keep these calls balanced.

The question then is where the extra mouseExit calls should happen. The most promising options are immediately before entering modal state, and immediately after exiting modal state.

Of the two options, I think the first option feels more consistent with the rest of JUCE’s mouse handling. Normally, a mouse source is only considered to be over a single component, so having a “stack” of mouseEnter events that are later matched by mouseExit calls (implying that the mouse source is logically over multiple components simultaneously) would be surprising to users. JUCE already has logic in place to send mouseEnter events to hovered components when a modal state ends, so it would make sense to send mouseExit events to hovered components just before a modal state starts too.

The downside of this approach is that it won’t work “out of the box” for @baconpaul’s use-case. As I understand it, the goal there was to paint a button in a special state if it is hovered, or if a popup menu is open. I’d consider “hover state” and “modal active state” to be different concepts, so I think it’s reasonable to require the state of the menu to be tracked separately, and to manually repaint the button when the menu is closed.

I’ll try adding extra mouseExit calls immediately before entering a modal state and make sure everything works in the way that I expect. In the meantime I’d welcome any thoughts/feedback you may have.

[baconpaul]

We actually argued about it a little and realized while it didn’t matter much end hover on menu close was epsilon more pleasing. If mouse exit had been called when the menu was opened we would have never even thought about it tbh so don’t guide your decision on my use case

I think calling mouse exit when you launch the popup is smart and the right semantic.

[asimilon]

The same issue described in a different way : Could isMouseOver() be fixed or do I just need to keep working around?

At least it seems like this is getting some traction now and might get fixed!

[reuk]

MouseEnter/mouseExit calls should now be properly balanced.

Component: Ensure that mouseEnter and mouseExit calls are balanced when entering/leaving modal state

Please try out this change and let us know if you encounter any new problems.