Search Issue Tracker
Fixed
Fixed in 2021.3.40f1, 2022.3.33f1, 6000.0.3f1
Votes
1
Found in
2021.3.37f1
2022.3.26f1
2023.2.19f1
6000.0.0b16
7000.0.0a1
Issue ID
UUM-70231
Regression
No
Context menus open on a different monitor when there are three monitors used
Reproduction steps:
1. Create a new 3D project
2. Right-click in the Hierarchy window
Expected result: The context menu opens on the same monitor where the Editor exists
Actual result: The context menu opens on a different monitor
Reproducible with: 2021.3.37f1, 2022.3.26f1, 2023.2.19f1, 6000.0.0b16
Reproducible on: Windows 10
Not reproducible on: No other environment tested
Notes:
- To reproduce 3 monitors are required
- The 3rd display must have a different Scale Factor than the other 2
- The monitors must be in this configuration:
display1 | display2
display3
- The Editor (or one of the windows) needs to be placed on display3; ContextMenus opened on this display will sometimes appear on the other displays
- The bug is _inconsistent_ sometimes menu appear correctly and other times appear on a different display; the specifics of this behavior or currently unknown
- All the Editor’s undocked windows also open on a different monitor
UPDATE:
This issue occurs due to the way Windows presents desktop coordinate spaces when using multiple displays with different DPIs or Scaling. If a given display has a different DPI than the other, e.g. using a laptop display with 2 regular monitors, the workArea coordinates for the "up-scaled" display can overlap the spaces for the other displays.
That is, although the Windows Display Setting shows the 3rd display sitting below the other two monitors, it's a lie: the 3rd display is actually overlapping the other two. This means a given point within the desktop coordinate space can intersect multiple monitor spaces.
Unfortunately, Unity's MultiMonitor support doesn't handle this case very well: when attempting to determine the monitor a point is on, e.g. to open a ContextMenu, it cycles through all the displays and picks the first one the point intersects. But if the point intersects _multiple_ displays it may end up selecting the wrong one. Therefore the menu opens on the wrong display. Depending on the DPI/Scale and arrangement of the monitors the amount of overlap can vary greatly causing the bug to repro inconsistantly, i.e. it occurs only when the mouse is within the overlap space and do depending on the screen position when you click the menu may appear correctly or on the wrong monitor.
For the ContextMenu scenario, this can actually be (mostly) fixed by choosing the monitor based on the window that's opening the window (instead of the mouse point) and use the Win32 API MonitorFromPoint() to more accurately return the correct monitor. However, this still isn't perfect: if the source window you're right-clicking on spans _across_ monitors, Windows may still give us the wrong monitor, but it's still an improvement.
However, there are other scenarios affected by this issue, e.g. docking/undocking Unity windows on the 3rd display, that we cannot fix right now.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Spot Light with 'Box' Shape stops working when it collides with Mesh
- Accepting Asset Store EULA endless loop in Package Manager window
- “InvalidOperationException: Sequence contains no matching element“ error when reenabling a custom Debug Draw Mode
- Prefab that contains a layout group is marked as changed by the Editor when opened
- Emission animation does not appear when the "Emission Map" parameter is set to black in a Lit material
Resolution Note (fix version 6000.0.3f1):
Fixes Windows Editor ContextMenus opening on the wrong monitor when using a 3rd display with different DPI but doesn't address the issue with custom Unity DropDown menus/windows