[BR] Alert sound when opening nested modal window

After upgrading from to 6.1.1, I’m getting the “alert” beep whenever I have a modal window that opens another, so to say, “nested” modal window in front of itself.

I’m on macOS 11.4 and it only happens when the nested modal window has a native title bar.

It did not happen in JUCE 6.0.5, which was the version I was using before upgrading.
I have attached a minimal example program that demonstrates the issue:

AlertSoundTest2.zip (173.1 KB)

image

Beware that this may look like this other issue I was having, but it’s not the same thing: closing these windows doesn’t trigger the beep, so that other issue is still solved in 6.1.1, no regression AFAIK

Oh I actually noticed that one too, but didn’t get the time to investigate. But I think for me it happened before 6.1.1, and on Windows too.

I should take time to repro and confirm.

After a session of git bisect, I’ve found the “offending” commit to be this:

It’s followed immediately by another commit with a similar description: HWNDComponentPeer: Dismiss modals more proactively · juce-framework/JUCE@85facf6 · GitHub, so I suppose that could be the culprit for the Windows platform too, but I haven’t tested that.

The description says:

This change will make plugin views (and other heavyweight views) listen
to their containing window, and dismiss any blocking modal components,
such as PopupMenus when the window is moved or resized.

There appears to be a bug in the implementation because when I’m opening a new modal window, I’m not moving nor resizing any of the existing ones.

Aside from that, I can see the rationale for dismissing temporary modal components when a plug-in view is acted upon, for example by the DAW.
On the other hand, doing that for every Component that has an heavyweight view (i.e. I suppose that includes those with a native title bar. What about those added to the Desktop?) seems overkill, and bordering into “breaking change” territory. Or am I missing something?

I confirm that these are the offending commits.
And for me it happens precisely in a case where I open a plugin window from a modal dialog (I’m writing a host). In my code, I open the plugin editor from the modal window and then close this modal window.
If I comment out the content of void dismissModals(), no more alert sounds.

Edit: I simply changed my logic to dismiss the main modal window before instantiating the plugin editor, but I guess this is still a bug to some extent?

I think that the intended behaviour is useful. If you have an app window with a native titlebar, and that contains some popup menus, it’s expected that moving the app window, or creating new heavyweight windows will dismiss the menus.

At the same time, you’re right that the peer is currently a little too enthusiastic about trying to dismiss modal windows - if the modal window is itself a long-lived dialog, creating other windows probably shouldn’t attempt to dismiss it. It sounds like the peer should only try to dismiss the modal component if the modal component’s peer is marked with the “windowIsTemporary” flag. This way, popup menus and other transient windows will still be dismissed by creating a heavyweight window, but long-lived windows will not.

That seems more reasonable indeed.

That sounds reasonable indeed. If you have a proposed change that you wish to test before commit, I’d be happy to check if it’s effective on my side

I think my proposed change would be something like this:

modaldismiss.patch (1.4 KB)

This seems to work for the demo you posted, but I’d appreciate if you could try this out in your “real” project and see whether it behaves sensibly there.

1 Like

Thank you for the quick response, yes, this patch also solves the “beep” in my real-world case, thanks.

I notice this patch only deals with the macOS side of things, does Windows require a similar change?

Windows doesn’t seem to, but I have a similar fix for Linux.

Thanks for trying out the patch, I’ll get that merged shortly (hopefully - we’re working through quite a backlog of pending code review at the moment!)

1 Like

I’ve added those changes here:

Please try out these changes and let us know if you run into any further problems.

1 Like

Am i the only one, but with latest develop i get an alert sound each time i open/create a window now?
Not the case with master branch.
And i don’t know if it is related but the “Preferences” sub-menu in Apple’s menu is also broken.
Anyway i’ll investigate later and will open another thread with more details.

I’m not seeing either of these issues in the AudioPluginHost or Projucer. If you are still seeing this issue, please provide some sample code to reproduce the problem, and let us know the platform you’re using.

1 Like

@reuk FYI I got another report today that the ding occurs on Windows. Out of curiosity why do you say that Windows does not have this issue, although this commit was pushed?
I can try a minimal repro if needed, but it’s basically happening when opening a plugin window from a modal dialog.

I tested a few different JUCE apps (DemoRunner, AudioPluginHost, and the minimal repro from the initial post in this topic) and didn’t observe any unexpected calls to LookAndFeel::playAlertSound().

The handling of events/input is quite different between the different ComponentPeer implementations so it’s conceivable that an issue like this does not affect all platforms. However, it’s also possible that I overlooked something while testing. If you’ve observed behaviour that seems buggy, please provide some minimal code so that we can reproduce the issue here.

Thanks, that makes sense. I’ll investigate more and come with a repro (if I don’t end up finding that the issue is on my end).

It appears that i have a sound alert for each entry in the menu bar on macOS 11.6 ; Each time i select an item : bip. Nothing related to window creation. I’ll try to make a minimum exemple and/or find where it started to happen in commits history.