AudioDeviceSelectorComponent Bluetooth Midi window opens behind modals

MacOSX and iOS
1

If an AudioDeviceSelectorComponent is displayed to the user inside a JUCE modal window, such as the kind created via juce::DialogWindow::LaunchOptions::launchAsync(), and the user clicks the “Bluetooth MIDI” button, the macos Bluetooth window that opens will be behind the DialogWindow, and even clicking it won’t bring it to the top. Also, if the DialogWindow is large enough, the user won’t even have any indication that the Bluetooth menu was opened, since it will be completely obscured. Furthermore, if the users clicks the “Bluetooth MIDI” button again, it will open another Bluetooth menu, as many times as they click.

It seems like showing the AudioDeviceSelectorComponent in a modal DialogWindow is a pretty normal thing to do (e.g. an options menu) so this seems like a significant problem.

I think it would be reasonable to make the Bluetooth window modal?

2

FWIW this fixes the problem for me: changing this line in BluetoothMidiPairingWindowClass::show():

JUCE/modules/juce_audio_utils/native/juce_BluetoothMidiDevicePairingDialogue_mac.mm:

    [getController (self) showWindow: nil];

to:

    [getController (self) showWindow: nil];
    [getController(self).window setLevel: NSPopUpMenuWindowLevel];

This brings the new window above the DialogWindow and makes it stay on top.

(However NB that it does NOT make it modal, so the user can move the Bluetooth window out of the way and click the “Bluetooth MIDI” button several more times to open several Bluetooth windows, which seems pretty silly.)

2 Likes
3

Can you share more about how to reproduce this issue? On MacOS 15.4 the Bluetooth window always comes to front in my case, and it’s also possible to switch back and forth between the modal window and the Bluetooth window.

I think there’s a small detail missing. I’ll share my repro attempt, hopefully you can see what’s different compared to your case.

#pragma once

#include <JuceHeader.h>

using namespace juce;

class DeviceManagerComponent : public Component
{
public:
    DeviceManagerComponent (AudioDeviceManager& deviceManager)
        : audioDeviceSelector { deviceManager, 2, 2, 2, 2, true, false, false, false }
    {
        addAndMakeVisible (audioDeviceSelector);
        setSize (400, 300);
    }

    void resized() override
    {
        audioDeviceSelector.setBounds (getLocalBounds());
    }

private:
    AudioDeviceSelectorComponent audioDeviceSelector;
};

struct MainComponent : Component
{
    MainComponent()
    {
        deviceManager.initialiseWithDefaultDevices (2, 2);
        openDeviceManagerButton.onClick = [this] { openDeviceManager(); };
        addAndMakeVisible (openDeviceManagerButton);
        setSize (600, 400);
    }

    void resized() override
    {
        openDeviceManagerButton.setBounds (getLocalBounds().withSizeKeepingCentre (200, 40));
    }

    void openDeviceManager()
    {
        DialogWindow::LaunchOptions options;

        options.content.setOwned (new DeviceManagerComponent (deviceManager));
        options.dialogTitle            = "AudioDevicemanager";
        options.dialogBackgroundColour = getLookAndFeel().findColour (ResizableWindow::backgroundColourId);
        options.launchAsync();
    }

private:
    AudioDeviceManager deviceManager;
    TextButton openDeviceManagerButton { "Open AudioDeviceManager" };
};
1 Like
4

Thank you so much for looking at this, @attila !

After some digging, I found the difference between my app and your minimal test case: my app creates a desktop window that is set to alwaysOnTop, but is not visible most of the time. I added this to your test case as desktopComponent.

Obviously I understand why desktopComponent itself, were it to be visible, would appear on top of the bluetooth MIDI window. But somehow its existence, even while not visible, causes the bluetooth MIDI window to appear behind the dialog window.

My (perhaps misguided?) expectations here are that:

  1. The desktopComponent’s alwaysOnTop-ness would not have any effect on other windows when desktopComponent is not visible
  2. The desktopComponent wouldn’t ever affect the ordering of other windows relative to one another, regardless of desktopComponent’s visibility.
#pragma once

#include <JuceHeader.h>

using namespace juce;

class DeviceManagerComponent : public Component
{
public:
    DeviceManagerComponent (AudioDeviceManager& deviceManager)
        : audioDeviceSelector { deviceManager, 2, 2, 2, 2, true, false, false, false }
    {
        addAndMakeVisible (audioDeviceSelector);
        setSize (400, 300);
    }

    void resized() override
    {
        audioDeviceSelector.setBounds (getLocalBounds());
    }

private:
    AudioDeviceSelectorComponent audioDeviceSelector;
};

struct MainComponent : Component
{
    MainComponent()
    {
        deviceManager.initialiseWithDefaultDevices (2, 2);
        openDeviceManagerButton.onClick = [this] { openDeviceManager(); };
        addAndMakeVisible (openDeviceManagerButton);
        setSize (600, 400);

        desktopComponent.addToDesktop(0);
        desktopComponent.setAlwaysOnTop(true);
        desktopComponent.setVisible(false);
    }

    void resized() override
    {
        openDeviceManagerButton.setBounds (getLocalBounds().withSizeKeepingCentre (200, 40));
    }

    void openDeviceManager()
    {
        DialogWindow::LaunchOptions options;

        options.content.setOwned (new DeviceManagerComponent (deviceManager));
        options.dialogTitle            = "AudioDevicemanager";
        options.dialogBackgroundColour = getLookAndFeel().findColour (ResizableWindow::backgroundColourId);
        options.launchAsync();
    }

private:
    AudioDeviceManager deviceManager;
    TextButton openDeviceManagerButton { "Open AudioDeviceManager" };
    Component desktopComponent;
};
5

Yes I see. I think it would be enough to use the same logic we use for JUCE modal windows.

if (WindowUtils::areThereAnyAlwaysOnTopWindows())
    [getController (self).window setLevel: NSFloatingWindowLevel];
1 Like
6

A fix is now out on develop

1 Like
7

Awesome, thank you so much! I tested the commit and it solves the problem for me.