Context menu doesn't appear under mouse under certain multi-monitor scaling and position configurations

[florelaberge]

Bug Description:

Depending on specific placement and scaling configurations of a multi-monitor setup, the context menu will only appear under the mouse only under certain 'valid' part of the whole desktop (usually delimited by screens). If the cursor is in an 'invalid' section when right-clicking, the context menu appears at the edge of the 'valid' part of the desktop, away from mouse.

Also occurs on the standalone (dawless) version. Additionaly, the window of the standalone snaps back to the left when the cursor is about to cross to the right on to an 'invalid' entire screen. Example 3 shows that even though there is an 'invalid' section on only a part of Monitor3, the Surge XT window can be placed anywhere on that screen because the 'invalid' zone does not take up the whole display.

Surge XT Version:

• Version: confirmed on 1.3.4f7b97c6 & 1.4.nightly.c1589dc
• Plugin Type: [Confirmed on CLAP & LV2 versions]
• Bitness: [64-bit]

Reproduction Steps:

1. Use KDE Display Configuration menu or kscreen-doctor and set screens to odd scalings like in 'Failing Example 2' below
2. Open Surge XT in standalone version or with DAW of choice
3. DAW: Bring Surge XT window to an 'invalid' screen
   Standalone: Drag part of the Surge XT window on to an 'invalid' screen without crossing the mouse over to the
   'invalid' screen while dragging so the window doesn't jump back to a 'valid' part.
4. Right-click a UI element located in an 'invalid' section of the desktop to open a context menu.
5. Context menu doesn't appear under mouse, instead appears in a 'valid' section of the desktop.

Examples:

• Example 1, EXPECTED BEHAVIOR: Context menu appears properly under cursor on all 3 monitors
  Monitor1 1920x1080 scaled 75% > 2560x1440 Position: 0,0
  Monitor2 3840x2160 scaled 150% > 2560x1440 Position: 2560,0
  Monitor3 2560x1440 scaled 100% > 2560x1440 Position: 5120,0

• Failing Example 2, PREFERED SETUP MIXED SCALING: Context menu appears close to the right corner of Monitor 1. I was also able to make it work up to Monitor2 on some configurations, but not consistently. Aligning all monitors on y-axis seems to help.
  Monitor1 1920x1080 scaled 90% > 2022x1137 Position: 0,0
  Monitor2 3840x2160 scaled 145% > 2439x1372 Position: 2022,0
  Monitor3 2560x1440 scaled 105% > 2439x1372 Position: 671,0

• Failing Example 3, ODD VERTICAL PLACEMENT TEST: As the Surge XT window goes further down, the context menu starts sticking at around middle of y-axis on Monitor 3. Works as intended on the upper section of the monitor.
  Monitor1 1920x1080 scaled 75% > 2560x1440 Position: 0,0
  Monitor2 3840x2160 scaled 150% > 2560x1440 Position: 2560,0
  Monitor3 2560x1440 scaled 100% > 2560x1440 Position: 5120,669

Expected Behavior:

The context menu always appears under mouse, no matter where the Surge XT window is located on the desktop.

Computer Information:

• OS: Debian 13.2 KDE plasma 3.3.6 (confirmed on Wayland & X11)
• Host: confirmed on Surge XT standalone & Reaperv7.55 & Ardour8.12.0
• GPU: Nvidia RTX 2070 (proprietery driver 550.163.01)

My Workaround:

Set up different display configuration profiles (shell scripts containing kscreen-doctor commands) and switch to one that works, like Example 1 above, when working with Surge XT. Slightly invonvenient, but preserves my workflow for now.

Additional Information:

Please let me know if more info is needed!

[baconpaul]

Well thank you for a very detailed bug report.
We just rely on juce to show the menu. I’m wondering if other juce plugins exhibit the same behavior. In surge land you could try shortcircuit or obxf but also there’s a million others kicking around.

I can’t imagine this would be something specifically in surge, and it is quite a difficult case to setup and debug. But if it is exhibited by other juce plugins I’m happy to bring it to the attention of the juce team!

If you are a developer I could also peek at the code and offer a few thoughts on ways to debug juce positioning if we determine it is a common problem,