Pro Tools 2023.3 - popups not working

[pflugshaupt]

Awesome find! I can confirm all my plugins have components that want keyboard focus - explaining why they are not affected by the problem.

[ericsen]

Nice! Seems to be the same reason in my case. Setting a button in the editor to want keyboard focus makes all popup-menus work again.

[reuk]

Thanks for providing a code example.

I’ve tried this out by generating a new Projucer plugin project, replacing the default editor with this one, enabling the AAX format, and then running it in Pro Tools Developer 2022.12 on Ventura 13.3 Intel. Triggering the first two menu items by clicking on them, or highlighting them and pressing ‘enter’, causes the colour of the text to change.

I’ll try downloading and testing Pro Tools 2023.3. In the meantime, I wonder whether you’ve made any other changes to the default build (module flags, editor-wants-keyboard-focus, extra modules). If so, it would be useful if you could provide the entire project including the jucer file or CMakeLists.

[chkn]

Thanks!

The problem appears only in 2023.3.

I created a default plugin project in projucer with no additional changes other than deployment target 10.9 (which probably has no effect on the end-result). I used the latest state from juce7/develop / Xcode 13.4.1

[pflugshaupt]

+1 only 2023.3 is affected… It does feel like a bug that Avid/Pro Tools should fix (thinking about breaking existing plugins), but getting a workaround for Juce is probably quicker.

[jakob-2]

As the question came up: Yes, all our plugins, including ShaperBox, are built with JUCE. ShaperBox 3 is still on JUCE 6 right now, but we’ve just tested with both the latest master (JUCE 7.0.5) and with the latest version of the development branch:

On both Intel and Apple Silicon on macOS 13.3 Ventura with the latest version of Pro Tools (2023.3), menus in out plugins do not open when we click on the ComboBox component. They do open however when we tap instead. (Uh?)

Menus open just fine with an older version of Pro Tools (2020.12) (also tested on macOS 13.3 Ventura).

We’ve also just tested with the latest reFX Nexus, asuming they’re also using JUCE, and menus do not open on the latest Pro Tools on macOS 13.3 Ventura.

VST and AU in other DAWs work fine for us.

[jakob-2]

We just tried this: getTopLevelComponent()->setWantsKeyboardFocus(true);

This does not fix it for us. Or did I misunderstand something regarding a possible workaround?

[chkn]

Try to add a button (or use an existent button on the editor) which setWantsKeyboardFocus(true);

beware if you may have something implemented like this (to prevent accidental catching of enter/return presses)

buttonClicked() fires when user presses return/enter key?

you could add this to your plugin gui component, which iterate through all child (and nested child) objects just call disableAllButtonsKeyboardFocus() in the constructor void disableAllButtonsKeyboardFocus() { disableAllButtonsKeyboardFocus(*this,*this); } void disableAllButtonsKeyboardFocus(AudioProcessorEditor& me,Component& component) { for (int i=0; i<component.getNumChildComponents(); i++) { Component* child=component.getChildComponent(i); child->setWantsKeyb…

[jakob-2]

@chkn

Try to add a button (or use an existent button on the editor) which setWantsKeyboardFocus(true);

So I just did exactly this - it does not work for us. Strange, that it does for you and not for us, though…

[AlexXandreE]

In the current project I just delayed the focus lost call by sending the request to the main thread again…
Not pretty but solve the issue for me, just make sure the view still exist at the call point.

juce::MessageManager::getInstance()->callAsync(method);

[jakob-2]

Interesting idea, thank you for sharing it. So just tried this too… but unfortunately it does not fix it for me.

[AlexXandreE]

Oh, had some hope that the easy fix would save you also In my case was a matter of lost focus being called before mouse down.
The keyboard focus trick also didn’t work.
Good luck

[rcohen]

I was able to fix this issue in our plugins by enabling keyboard focus on the combo boxes that showed the problem. However, this is a bad user experience in Pro Tools. Return/Enter is used in PT for “Return to Zero”.

[jakob-2]

We’ve now also been able to fix it. In our LookAndFeel class, we’ve added this code in preparePopupMenuWindow(juce::Component& newWindow):

juce::Timer::callAfterDelay(100, [bailOutChecker = std::make_shared<juce::Component::BailOutChecker>(&newWindow), &newWindow]() {
	if (!bailOutChecker->shouldBailOut()) {
		newWindow.setWantsKeyboardFocus(true);
		newWindow.setMouseClickGrabsKeyboardFocus(true);
		newWindow.grabKeyboardFocus();
	}
});

[jakob-2]

Ooops… the code that I had shared has the side effect that menus remain open on Windows when you click at some place besides the menu.

This is the code that we’re now using in our LookAndFeel class, in preparePopupMenuWindow(juce::Component& newWindow):

#ifdef JUCE_MAC
    juce::Timer::callAfterDelay(100, [bailOutChecker = std::make_shared<juce::Component::BailOutChecker>(&newWindow), &newWindow]() {
        if (!bailOutChecker->shouldBailOut()) {
            newWindow.setWantsKeyboardFocus(true);
        }
    });
#endif

[reuk]

We’ve got an official fix on the way for this issue.

[rcohen]

Thanks. For me, it turns out that some of our plugins were affected, and others not. Therefore a bit of a mystery.

[HowardAntares]

Shouldn’t Avid fix this? We use an older Juce version, so we won’t get any fixes in the new Juce version, but we still have the problem to deal with.

[jakob-2]

Definitely - I’ve just forwarded this to Avid.

[reuk]

The workaround on the JUCE side is now merged:

PopupMenu: Avoid dismissing menu in response to mouse events over the menu