I’m getting a weird bug with very long menus in Juce 8, but only in Ableton Live on Windows (I’ve not seen it happen in other DAWs yet).
If you have a long menu that is taller than the display, when you scroll down the menu until it reaches the end, the menu stops working and you will no longer be able to select an item. You need to click off the menu and start again. This makes it very difficult / impossible to select the last item of the menu —>
Are you in HiDPI mode, by any chance?
The issue occurs both when HiDPI mode is enabled and disabled.
This seems to be fixed with latest develop branch. Will test some more…
Ah, I was wrong, after testing it it still seems to be broken even with latest Develop branch, the menu items are now correctly being highlighted, but you are still not able to select items after scrolling the menu to the end.
I wasn’t able to reproduce the issue with the following setup:
To test, I added the following code to the editor constructor of a basic plugin project, where button is a member TextButton:
addAndMakeVisible (button);
button.onClick = [&]
{
juce::PopupMenu inner;
for (auto i = 0; i < 200; ++i)
inner.addItem ("item " + juce::String (i), [i] { DBG (juce::String (i)); });
juce::PopupMenu outer;
outer.addSubMenu ("inner", inner);
outer.showMenuAsync (juce::PopupMenu::Options{}.withTargetComponent (button).withMaximumNumColumns (1));
};
To help us track down the problem, please provide the following information:
Hi @reuk
Thanks for checking this out.
I am using a custom look and feel for my menu with the backgroundColourId set to ‘transparentWhite’ so that I can style the menu by rounding the corners, setting backgroundColourId to an opaque colour fixes the issue.
I was able to reproduce the issue using your code example by setting the editor’s default look and feel to this →
class PopupMenuLookAndFeel : public juce::LookAndFeel_V4
{
public:
PopupMenuLookAndFeel() {
setColour (juce::PopupMenu::backgroundColourId, juce::Colour::fromFloatRGBA(0.5f, 0.5f, 0.5f, 0.5f));
}
};
I’m using Windows 11, Live 11.3.25, tested on a couple of different setups.
It happens both when using the scroll wheel and hovering with the mouse.
When I build with the master branch I get the issue shown above: after reaching the end of the menu the mouse will stop highlight items when hovering.
When I build with the develop branch there’s a small improvement: the mouse will correctly highlight the menu items after reaching the end of the menu when hovering, but clicks on the menu are still not registered.
I narrowed down this change in the develop branch to this commit: Windowing: Avoid recursively calling WM_NCHITTEST in contains() · juce-framework/JUCE@515e9b9 · GitHub
here’s the demo project:
Test Menu.zip (29.5 KB)
Hi @reuk did you get a chance to try out the demo project above?
I saw this in modules/juce_gui_basics/native/juce_Windowing_windows.cpp, D2DContext constructor →
// Layered windows use the contents of the window back buffer to automatically determine mouse hit testing
// But - Direct2D doesn't fill the window back buffer so the hit tests pass through for transparent windows
//
// Layered windows can use a single RGB colour as a transparency key (like a green screen). So - choose an
// RGB color as the key and call SetLayeredWindowAttributes with LWA_COLORKEY and the key colour.
//
I’m wondering if there’s something I should be doing for a transparent menu background for my rounded corners, other than setting PopupMenu::backgroundColourId?
In the meantime I can just use square corners for the menus on windows and use an opaque background, which fixes the issue.
Thanks for the additional details. I’m now able to reproduce the issue.
The fact that this issue is only triggered when the menu is transparent makes me think that this issue may share a root cause with the issue discussed here:
Investigating these issues is now at the top of my to-do list. However, I’ve already spent a little time investigating the other issue without making much progress, so I’m not feeling particularly optimistic at the moment.
In general it’s best to avoid creating additional windows in your plugin editor. This is especially true for AUv3, and to a lesser extent, AU plugins.
Another option would be to set your plugin editor as the parent of your PopupMenu (see PopupMenu::Options::withParentComponent). This way, your menu will be restricted to the editor’s viewport, but transparency effects and rounded corners will work as expected. This approach is less likely to cause problems in AU versions of you plugin, such as the menu window opening behind the plugin editor window.
In particular, consider the official guidance from Apple for supporting out-of-process audio units:
- If custom, free-floating dialogs don’t work as you expect, add them as a subwindow to the main window — this includes custom tooltip and drop-down menu implementations.
OK thanks for the update! 
Another option would be to set your plugin editor as the parent of your PopupMenu (see
PopupMenu::Options::withParentComponent)
In my particular use case (for a sample selection menu), I need the menu windows to be extended outside of the bounds of the plugin window. It’s reading a set of folders with an arbitrary amount of samples and therefore the menu will often need to be quite long.
I have discovered that the issue occurs in other host than Ableton Live when that host is in full-screen mode. For example Bitwig and FL Studio on Windows are both exhibiting the issue when in full-screen mode, but not when the DAW’s main window is not full-screen.
I haven’t yet discovered this affecting AUv3 or AU plugins on MacOS, this currently seems to be only affecting Windows VST3.
Another update from our side: I spent the best part of last week looking into this, but I think I’ve landed on a solution that should work nicely. It’s still only a proof-of-concept at the moment, meaning I still need to refactor and tidy up, then get it reviewed. However, I’m optimistic we should be able to publish the changes in a week or two.
Thanks for the update. I spent a couple of days looking at it a while ago and got nowhere 
Looking forward to testing the fix in a few weeks
Thanks for your patience. We’ve now pushed an update that should fix the behaviour of transparent windows using the Direct2D renderer. The bulk of the relevant changes are in this commit:
This fix causes OpenGL rendering issues on Windows even with the Direct2D renderer disabled.
