BR: PopupMenu::Options::withTargetComponent broken in latest tip / AUv3

MacOSX and iOS
1

JUCE AUv3 plugin built with the latest tip, the PopupMenu always appears in the top left corner of the AUv3 plugin if the iOS device is running in landscape mode, instead of near the target component that was specified with withTargetComponent()

Tested in AUM, on both iOS26 and iOS18.6.2

In the code example below that is used to trigger the popup menu, ‘m_editor’ refers to the AudioProcessorEditor class, and ‘this’ refers to a button in a child component to trigger the popup menu, which is near the right edge of the screen (also see remark below).

    PopupMenu::Options options = PopupMenu::Options()
        .withTargetComponent(this)
        .withParentComponent(m_editor);
    
    m_dropDownMenu.showMenuAsync(
        options,
        ModalCallbackFunction::forComponent(handleMenuModalCallback, this));

The exact same code works perfectly fine in the iOS stand-alone version, and also works fine on macOS (AU, stand alone)

Interestingly though, the popup menu only shows up full left if the button to trigger it, and which is passed on as withTargetComponent() is near the right edge of the editor in landscape. If that button is moved further to the left, the menu does show up in the correct location.

1 Like
iOS 26 - Bug in display user area
2

Interestingly, in the MenuWindow::getParentArea() function where the target area is calculated from Desktop::getInstance().getDisplays().getDisplayForPoint(), the totalArea has w = 1194, h = 834, while the userArea seems to have these numbers flipped (w = 834, h = 1194), with AUM / phone in landscape orientation, but only on iOS26.

On iOS18, is even weirder, where the parent component has w > h (because the app is in landscape), but the totalArea and userArea returned by Desktop::getInstance().getDisplay().getDipslayForPoint() have both h > w (e.g. h and w flipped).

Given these flipped size properties, and the intersection operation with the parent/target component itself, the resulting target area where to put the menu becomes empty, and therefore the menu ends up in the top left corner of the UI. So it seems the bug for AUv3/iOS/AUM is in the Desktop::Display class returning the wrong dimensions of the user and total areas when the device is in landscape mode and the plugin itself also has w >h, and the withTargetComponent is near the right edge of the screen?

3

Save yourself endless pain on iOS and replace popupmenus’ with sliding drawers, which are a far better user experience and more future-safe. The effort you spend trying to fix popups is better spent on the sliding drawer paradigm. Your users will benefit, and you’ll have less code to maintain as progress marches on ..

4

@ibisum Agreed. And we have some sliding menus already. However, these will also need some logic on iOS to determine where the menu can appear, drawing on similar functions in JUCE’s Desktop/Display class that currently seem to give inconsistent results. As far as I can tell the PopupMenu code itself is ok, while the issue of menus appearing in the wrong locations is rooted deeper in JUCE code and therefore worth looking into. But happy to be proven wrong by the JUCE team.

1 Like
5

Thanks for reporting. I believe these issues are now fixed on the develop branch.