# Juce 8 bug with long menus in Ableton Live

**URL:** <https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973>\
**Category:** Direct2D\
**Created:** [June 25, 2024, 7:26am UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973 "2024-06-25T07:26:03Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![davidleonalex](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@davidleonalex](https://forum.juce.com/u/davidleonalex)\
**Post date:** [June 25, 2024, 7:26am UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/1 "2024-06-25T07:26:03Z")

</div>

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 —\>

![menu-bug](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/e/3/e3efe7500121a669323f2df3dbef3e5cfcae6590.gif)

---

<div class="post-metadata">

**Author:** ![QuilioLtd](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/quilioltd/32/15459_2.png) [@QuilioLtd](https://forum.juce.com/u/QuilioLtd)\
**Post date:** [June 25, 2024, 10:39pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/2 "2024-06-25T22:39:23Z")

</div>

Are you in HiDPI mode, by any chance?

---

<div class="post-metadata">

**Author:** ![davidleonalex](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@davidleonalex](https://forum.juce.com/u/davidleonalex)\
**Post date:** [July 6, 2024, 9:18am UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/3 "2024-07-06T09:18:27Z")

</div>

The issue occurs both when HiDPI mode is enabled and disabled.

---

<div class="post-metadata">

**Author:** ![davidleonalex](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@davidleonalex](https://forum.juce.com/u/davidleonalex)\
**Post date:** [July 6, 2024, 11:50am UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/4 "2024-07-06T11:50:55Z")

</div>

This seems to be fixed with latest develop branch. Will test some more…

---

<div class="post-metadata">

**Author:** ![davidleonalex](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@davidleonalex](https://forum.juce.com/u/davidleonalex)\
**Post date:** [July 6, 2024, 8:24pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/5 "2024-07-06T20:24:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [July 9, 2024, 11:46am UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/6 "2024-07-09T11:46:03Z")

</div>

I wasn’t able to reproduce the issue with the following setup:

- JUCE 8.0.0 tag or JUCE develop
- Windows 11
- Ableton Live 12.1 beta 3
- Plugin auto-scaling enabled or disabled
- Windows display scale 100% or 200%

To test, I added the following code to the editor constructor of a basic plugin project, where `button` is a member TextButton:

```auto
    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:

- Is the issue present if you add the above code to a new, blank project using JUCE’s develop branch? If not, then the issue may be related to particular customisations you’ve made to your PopupMenu. Otherwise, the issue might only surface when using a particular combination of host and/or OS version.
- What version of Live are you using for testing? If you try another DAW (e.g. REAPER), is the issue present there?
- What’s the exact sequence of inputs you’re using to navigate the menu? i.e. are you using the scroll wheel, or just hovering over the bottom of the menu?

---

<div class="post-metadata">

**Author:** ![davidleonalex](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@davidleonalex](https://forum.juce.com/u/davidleonalex)\
**Post date:** [July 11, 2024, 9:00am UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/7 "2024-07-11T09:00:39Z")

</div>

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 →

```auto
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](https://github.com/juce-framework/JUCE/commit/515e9b9f89ed2af8e541d19493929c0be2556066)

here’s the demo project:

[Test Menu.zip](https://forum.juce.com/uploads/short-url/y9VVNLZ1EDlVcmYr5xH1PwWJnCt.zip) (29.5 KB)

---

<div class="post-metadata">

**Author:** ![davidleonalex](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@davidleonalex](https://forum.juce.com/u/davidleonalex)\
**Post date:** [July 25, 2024, 1:00pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/8 "2024-07-25T13:00:14Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [July 30, 2024, 5:57pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/9 "2024-07-30T17:57:14Z")

</div>

> [@davidleonalex](#):
>
> Hi @reuk did you get a chance to try out the demo project above?

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:

> [@BR: DocumentWindow broken in VST3 when transparent since JUCE 8](https://forum.juce.com/t/br-documentwindow-broken-in-vst3-when-transparent-since-juce-8/61933):
>
> DocumentWindow stops capturing mouse clicks after being resized when it is in a PluginEditor on Windows. The problem is not present when compiling as a Standalone but is when in a VST3. Everything works fine in JUCE 7. Steps to reproduce: Start a new plugin project. Add a juce::DocumentWindow to the Editor. Use the constructor below. Compile and open the VST3. Resize the window by dragging on the bottom right corner. The DocumentWindow no longer responds to clicks. Impossible to move or resiz…

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.

> [@davidleonalex](#):
>
> In the meantime I can just use square corners for the menus on windows and use an opaque background, which fixes the issue.

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](https://developer.apple.com/documentation/audiounit/debugging_out-of-process_audio_units_on_apple_silicon?language=objc) 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.

---

<div class="post-metadata">

**Author:** ![davidleonalex](https://avatars.discourse-cdn.com/v4/letter/d/58f4c7/32.png) [@davidleonalex](https://forum.juce.com/u/davidleonalex)\
**Post date:** [August 12, 2024, 12:49pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/10 "2024-08-12T12:49:18Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [August 12, 2024, 2:34pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/11 "2024-08-12T14:34:49Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![pstitt01](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/pstitt01/32/2610_2.png) [@pstitt01](https://forum.juce.com/u/pstitt01)\
**Post date:** [August 12, 2024, 2:38pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/12 "2024-08-12T14:38:39Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [August 23, 2024, 7:58pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/13 "2024-08-23T19:58:43Z")

</div>

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:

> <https://github.com/juce-framework/JUCE/commit/340f531c71ebc62979e8c5ae9f18df26bf43a2d8>

---

<div class="post-metadata">

**Author:** ![psyDSP](https://avatars.discourse-cdn.com/v4/letter/p/f04885/32.png) [@psyDSP](https://forum.juce.com/u/psyDSP)\
**Post date:** [August 23, 2024, 11:11pm UTC](https://forum.juce.com/t/juce-8-bug-with-long-menus-in-ableton-live/61973/14 "2024-08-23T23:11:30Z")

</div>

> [@reuk](#):
>
> We’ve now pushed an update that should fix the behaviour of transparent windows using the Direct2D renderer.

This fix causes OpenGL rendering issues on Windows even with the Direct2D renderer disabled.

> [@\[Bug\] OpenGL rendering issues with latest JUCE 8 develop on Windows](https://forum.juce.com/t/bug-opengl-rendering-issues-with-latest-juce-8-develop-on-windows/62599):
>
> Rendering OpenGL subcomponents with Direct2D rendering disabled causes plugin windows to become completely transparent in some DAWs. When Direct2D rendering is enabled, certain elements on the OpenGL subcomponent such as text are not rendered. This issue is introduced by commit 340f531 and does not occur when the plugin editor is attached to an OpenGL context rather than a subcomponent. Here are some images demonstrating the issue on Windows 11 with scaling set to 100%. These images were taken …