It happens on macOS when the parent Component is added to desktop with the windowIgnoresKeyPresses flag.
Check the attached video: in the green component, the button hover animation works as expected when the component has focus (displayed with a white rectangle drawn inside the focused component).
On the other hand, in the red component the hover animation for the buttons never works, even after the component has been clicked to make it the focused one.
Curiosly enough, when the red component is clicked after the green, the green loses the focus as expected (the white rectangle inside disappears) but the red doesn’t gain it. And in this situation, the hover animation is still working for the buttons inside green (instead of those inside red, as it should)
The only difference between green and red is that green is added to desktop with addToDesktop (0), red with addToDesktop (juce::ComponentPeer::windowIgnoresKeyPresses).
Stepping with the debugger, it can be seen that the lack of hover animation is due to those buttons not receiving their mouseEnter/Exit events.
Code is also attached, simply create a new GUI project with Projucer and replace MainComponent.h/.cpp with those attached.
The documentation for that flag could be clearer (we’ve updated it in 091ab8a) - it actually prevents the window from gaining keyboard focus entirely, not just for receiving key events. Having the keyboard focus is necessary on macOS for the window to receive mouse movement events so the hover animation won’t work for windows with this flag set.
This is a bug and should be fixed in f43784d - the window with windowIgnoresKeyPresses set will never grab the focus and other windows will correctly propagate focus loss events when resigning the key window status.
Having the keyboard focus is necessary on macOS for the window to receive mouse movement events so the hover animation won’t work for windows with this flag set.
Thanks, I can confirm this behavior is now consistent with the rest of the OS: loss of focus → hover animation doesn’t happen as expected.
Both of these statements are a little wide of the mark. As I’m typing this I can trigger hover animations in a Finder window, so mouse events are expected to be received without having keyboard focus. This is also the same behaviour as on the other platforms we support.
Reverting the commits also addresses the regression mentioned in this thread:
