[vogella]

On Wayland a client is never told where its window is, so SWT returned window relative display coordinates while Monitor geometry stayed global. Anything that clips a location against a monitor was therefore mixing two coordinate spaces, which the JFace information controls do: on a multi-monitor layout whose client areas do not start near y=0, every candidate position is rejected, so javadoc hovers came up empty and the content assist javadoc popup opened on a different monitor.

Wayland does tell us which monitor a surface is on, so display coordinates are now anchored to that monitor origin and the offset is removed again when a window or menu is positioned. A whole shell tree uses the monitor of its root toplevel as the one anchor, since child shells are positioned relative to their parent and a hidden or edge-straddling popup reports no or a different monitor of its own. Display.getCursorLocation() is anchored the same way, since callers compare it against Control.toDisplay().

Fixes #3539
Fixes #538

The reporter of #3539 confirmed both the empty hovers and the misplaced content assist popup are gone on their three monitor setup. #538 is the same root cause reported from several setups, all of them with a second monitor whose top edge is not aligned with the primary, and all of them worked around by aligning the monitors. The window position within its monitor is still unknown, but popups are placed relative to their parent and unaffected by that. X11 and GTK4 are unchanged.

[vogella]

@akurtakov in case you have time, please review, its in two commits to separate the two different changes, the first one is a protection against bad callers, the second the fix for the issue.

[Copilot]

Pull request overview

Anchors GTK3 Wayland coordinates to monitor origins and prevents invalid negative shell allocations.

Changes:

• Aligns shell, control, cursor, and menu coordinates with monitor geometry.
• Converts display coordinates back before native positioning.
• Clamps shell content allocations to non-negative sizes.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
Shell.java	Anchors shell coordinates and hardens allocation sizing.
Menu.java	Converts popup positions to shell-relative coordinates.
Display.java	Anchors cursor coordinates to a monitor.
Control.java	Adds monitor-aware coordinate conversion.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Test Results

 1 017 files  ± 0   1 017 suites  ±0   1h 24m 56s ⏱️ + 10m 48s
 5 059 tests + 2   5 031 ✅ +2     28 💤 ± 0  0 ❌ ±0 
29 719 runs  +12  27 177 ✅ +2  2 542 💤 +10  0 ❌ ±0 

Results for commit 966d12d. ± Comparison against base commit eeb3482.

♻️ This comment has been updated with latest results.

[akurtakov]

Needs manual rebase.

[vogella]

I'm using this patch since weeks in my custom IDE build and plan to merge this tomorrow unless I hear otherwise.

[Copilot]

Copilot review overview

🟡 Changes recommended

Cursor anchoring mishandles zero-origin monitors and fails whenever no shell is active.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Distinguish a valid primary monitor origin from lookup failure · New
• Force regression test to use a monitor with a non-zero origin · New

Resolved since last review (2)

• The offset is selected from activeShell, but the cursor may be over a different SWT shell on…
• This always uses the logical parent's monitor, even after the child shell is mapped. A…

[akurtakov]

I don't have the multimonitor setup to properly test but my claude analysis pointed few things, it would be nice to try them just so we are sure:

Blocking

1. Drag-and-drop into Tree/Table breaks on a non-primary monitor

• DropTarget.java:~879 still builds event.x/y from the raw gdk_window_get_origin() + local, with no anchor.
• Everything that uses those coordinates converts back with toControl(), which now subtracts the anchored origin:
  • DropTargetEffect.getItem() (lines 100 and 118)
  • TableDropTargetEffect:138
  • TreeDropTargetEffect:159
  • ViewerDropAdapter and anything else in user code that calls toControl(event.x, event.y)
• Result: on a monitor at (1920,0), getItem looks up x−1920. That gives no item (or the wrong one), and the insert/scroll feedback goes wrong. The Package Explorer and other viewer drag-and-drop would be affected.
• Fix: DropTarget should use control.toDisplay(x, y), or apply the same anchor.

2. Dialogs get the wrong anchor

• Shell.monitorOrigin() does if (parent != null) return parent.monitorOrigin() for every child shell. The reasoning ("a child Shell is positioned relative to its parent") only holds for ON_TOP child shells, which are GTK_WINDOW_POPUP (Shell.java:775).
• Every other child shell (dialogs, wizards, SWT.TOOL without ON_TOP) is a GTK_WINDOW_TOPLEVEL with transient_for. On Wayland each of those has its own coordinate system, and the compositor can put it on another monitor.
• In that case toDisplay() inside the dialog uses the parent's monitor while dialog.getMonitor() returns the dialog's own. That is the same kind of mismatch this PR is fixing, now in dialogs.
• Fix: use the parent's anchor only for popup shells (or while the shell is unmapped); otherwise use the shell's own window.

Should fix

3. getCursorLocation() uses a different anchor than toDisplay()

• It prefers monitorOrigin(pointerWindow), the monitor of whatever window is under the pointer.
• The PR's own reasoning says to avoid that: a popup straddling a monitor edge reports a different monitor than its root toplevel.
• So with the pointer over such a popup, getCursorLocation() and toDisplay() differ by a whole monitor offset. That breaks JFace hover "is the mouse still inside" checks.
• Fix: map pointerWindow to its SWT control (gdk_window_get_user_data → display.getWidget) and use getShell().monitorOrigin().

4. Other callers of gtk_window_move weren't updated

• ToolTip (SWT.BALLOON, a GTK_WINDOW_POPUP, lines ~212–284 and 594) passes display coordinates straight to gtk_window_move. It will now be off by the monitor origin when callers use toDisplay().
• Tracker (Tracker.java:826) draws with rectangles in display coordinates but compares them against raw pointer positions. Same kind of drift, lower impact.
• Accessibility extents in AccessibleObject.java (lines 4537 and 4557) also stay unanchored. That matters less, since screen readers on Wayland can't use global coordinates anyway.

5. The anchor can change between set and get

• setBounds subtracts the anchor that applies when it's called. If the parent (or the shell itself) isn't realized yet, there is no anchor, but getLocation() after mapping adds one. setLocation(p) then getLocation() no longer returns p.
• The anchor also changes when the root window moves to another monitor, and no SWT.Move event is sent. Every cached display coordinate becomes stale.
• Neither is necessarily a blocker, but both should at least be written down in the code or commit message.

[vogella]

Thanks, updated the commit.

1. Fixed. DropTarget now adds the monitor origin of the shell tree, so toControl() in the drop effects matches again. I did not use control.toDisplay(x, y): for Tree and Table toDisplay() is relative to the bin window, which would shift the drop position by the header height.
2. Agreed on the analysis, but it is not a regression: dialogs on a monitor with a non-zero origin were broken before this PR as well. I'd like to handle transient toplevels in a follow-up so this one stays focused on popups.
3. Fixed. getCursorLocation() now takes the anchor from the SWT shell tree under the pointer, falling back to the active shell, so it matches toDisplay(). This also fixes the zero-origin monitor issue Copilot flagged.
4. Fixed for the balloon ToolTip, the Tracker overlay and pointer positions, and also for the IME preedit window, which had the same problem (gtk_window_move() with toDisplay() coordinates). Accessibility needs no change: the extents only go out to AT-SPI and are never converted back by SWT, so they cannot mismatch with toDisplay().
5. Documented in the commit message.

[Copilot]

Copilot review overview

🟡 Changes recommended

Several cursor, tooltip, and tracker paths still mix anchored and unanchored Wayland coordinates.

Review effort: Balanced
Findings: 4 · 1

Open (5)

• Consult pointer window when no active shell exists · New
• Restore parent monitor origin for default locations · New
• Anchor all pointer samples for parentless trackers · New
• Distinguish a valid primary monitor origin from lookup failure
• Force regression test to use a monitor with a non-zero origin

[vogella]

Addressed the Copilot findings in the updated commit:

• Zero-origin monitor in getCursorLocation(): fixed, the anchor now comes from the SWT shell tree under the pointer, so a monitor at 0,0 is no longer mistaken for a failed lookup.
• activeShell == null: the anchor lookup now runs without an active shell, which is only needed for the popup offsets.
• Balloon ToolTip at the pointer position: the monitor lookup now adds the anchor for every location except the tray item.
• Tracker(Display): all pointer samples, including the key and resize paths, go through one helper that adds the anchor.
• Regression test with a non-zero monitor origin: a test cannot choose the monitor the compositor maps a window on, so the tests only bite on a multi-monitor Wayland session, as noted in the commit message.

[Copilot]

Copilot review overview

🟡 Changes recommended

Tracker overlays can become invisible on monitors positioned left of or above the primary display.

Review effort: Balanced
Findings: 1

Open (1)

• Tracker invisible on monitors with negative coordinates · New

Resolved since last review (5)

• Anchor all pointer samples for parentless trackers
• Restore parent monitor origin for default locations
• Consult pointer window when no active shell exists
• Distinguish a valid primary monitor origin from lookup failure
• Force regression test to use a monitor with a non-zero origin

[vogella]

All findings are handled in 8be39a7:

• Tracker overlay with negative monitor origins: the overlay now spans the union of all monitors and the region is offset to match.
• getCursorLocation without an active shell: the lookup of the window under the pointer no longer depends on activeShell, which is now only the fallback.
• ToolTip default location: the monitor origin is applied to every location except a status item.
• Tracker pointer samples: all pointer readings go through getPointerPosition(), which anchors them.
• Monitor at (0,0): the anchor comes from the control under the pointer, so null only means "no offset".
• Single-monitor test: correct, as the commit message notes. Making it fail against the old code needs a lookup that can be swapped out, which is out of scope here.

[Copilot]

Copilot review overview

🟡 Changes recommended

Cursor offsets can still mix active and pointer shell trees, and the added tests do not exercise non-zero monitor origins.

Review effort: Balanced
Findings: 1

Open (1)

• Use pointer shell for parent offsets and monitor anchoring · New

Resolved since last review (1)

• Tracker invisible on monitors with negative coordinates

[vogella]

Fixed

[Copilot]

Copilot review overview

🟡 Changes recommended

Tracker changes affect X11 and GTK4 despite the stated backend scope.

Review effort: Balanced
Findings: 1

Open (1)

• Avoid changing overlay bounds on X11 and GTK4 · New

Resolved since last review (2)

• Tracker invisible on monitors with negative coordinates
• Use pointer shell for parent offsets and monitor anchoring

[Copilot]

Copilot review overview

🟡 Changes recommended

The new tests do not deterministically exercise Wayland with a nonzero monitor origin, so they cannot catch the reported regression on standard CI layouts.

Review effort: Balanced
Findings: 1

Open (1)

• Test Wayland popup translation with a nonzero monitor origin · New

Resolved since last review (1)

• Avoid changing overlay bounds on X11 and GTK4