CallOutBox is not dismissed when clicking inside of a WebBrowserComponent

MacOSX and iOS
1

Hi! I’m currently having an issue with CallOutBoxes where they are not dismissed when clicking inside of a WebBrowserComponent. This only happens on macOS when testing in a DAW (it doesn’t happen in standalone).

Anyone has an idea of how I can fix this?

Thanks!

2

Hello,
I have the same problem usign a viewport inside a calloutbox.
For some reason, and only on MacOS, the inputAttemptWhenModal triggers as soon as the launchAsynchronously method is called, and the calloutbox is dismissed.
Since there is no runModalLoop method anymore, I’m confused about how to set dismissalMouseClicksAreAlwaysConsumed because the inputAttemptWhenModal is called before being able to set it, so it will always be false at this stage and there is no way to change that.

in the CalloutBox cpp file, commenting out the dismissal on line 152 seems to fix it :

#if !JUCE_MAC 
        exitModalState (0); 
        setVisible (false); 
#endif

EDIT : this was a bit too quick a fix, and a bit too stupid… while this works, the modal state is never exited when commenting out this line. I guess this has to be dealt with at a deeper level, but I have no clue where to check. I tried setting all my components setWantsKeyboardFocus to false, that helped to some extent but not fully.

3

This is the stack trace, stopped at inputAttemptWhenModal.
It is triggered as soon as launchAsynchronously is called, next line is setDismissalMouseClicksAreAlwaysConsumed but is called after, and the box has already been closed.

image
image671×766 137 KB

4

As a probably ugly fix, forcing dismissalMouseClicksAreAlwaysConsumed to true on Mac seems to do the job.

in CalloutBox header file :

#if JUCE_MAC 
    bool dismissalMouseClicksAreAlwaysConsumed = true; 
#else 
    bool dismissalMouseClicksAreAlwaysConsumed = false; 
#endif
5

Thanks for including a stack trace in your report, it helped to track down the issue quickly. It looks like opening the new modal window causes the previously-focused window to resign key status, which in turn causes it to dismiss its modal components.

I’ve pushed a fix here: