Description
When using OpenGuider with a dual-monitor setup, the pointer hint (the visual indicator that shows where to click) appears on the secondary monitor instead of the monitor where the target application is open.
Because the pointer hint is rendered on the wrong display, when it tries to move toward the correct target coordinate, it reaches the right edge of the secondary monitor and disappears — it never actually reaches the intended UI element on the primary monitor.
Steps to Reproduce
- Set up a dual-monitor configuration (primary monitor on the left, secondary on the right).
- Launch OpenGuider. Open a target application on the primary monitor.
- Ask OpenGuider a question that requires a pointer hint (e.g. "Where do I click to open Settings?").
- Observe the pointer hint location.
Expected behavior:
The pointer hint should appear on the same monitor as the target application and move to the correct UI element.
Actual behavior:
- The pointer hint appears on the secondary monitor instead of the primary.
- As it tries to animate toward the target coordinate, it reaches the right edge of the secondary monitor and vanishes off-screen, never reaching the actual target.
Root Cause Hypothesis
The pointer hint coordinate is likely being calculated correctly in absolute virtual desktop space (e.g. x: 1980, y: 540 targeting the primary monitor), but the overlay BrowserWindow is being created anchored to the secondary monitor's origin instead of the primary.
This means the hint's local coordinates within the overlay are offset — the overlay interprets the absolute position relative to the wrong display origin, pushing the hint past the edge of the secondary screen.
Relevant areas to investigate:
renderer/ cursor overlay window — check which display the overlay BrowserWindow is being positioned on at creation time.
main.js — check if screen.getAllDisplays() is used to find the correct display for the active/target window, or if the overlay defaults to display index [1] instead of [0].
- Coordinate mapping — when translating absolute screenshot coordinates into overlay-local coordinates, the origin of the correct display (
display.bounds.x, display.bounds.y) must be subtracted, not the secondary display's origin.
Suggested Fix
- Detect which display the target application window is on using:
const targetDisplay = screen.getDisplayNearestPoint({ x: targetX, y: targetY });
- Create (or move) the cursor overlay
BrowserWindow to be positioned on targetDisplay.bounds.
- When passing pointer hint coordinates to the renderer, subtract the correct display origin:
const localX = absoluteX - targetDisplay.bounds.x;
const localY = absoluteY - targetDisplay.bounds.y;
- Clamp final coordinates within
targetDisplay.bounds to prevent off-screen rendering.
Environment
- OS: Windows 11
- Monitor setup: Dual monitor — primary on the right, secondary on the left
Additional Notes
- Single monitor setup works correctly.
- The pointer hint disappearing to the right is a symptom of wrong display origin, not a separate bug — the hint is moving in the correct direction but on the wrong screen, so it exits through the right edge before reaching the target.
Description
When using OpenGuider with a dual-monitor setup, the pointer hint (the visual indicator that shows where to click) appears on the secondary monitor instead of the monitor where the target application is open.
Because the pointer hint is rendered on the wrong display, when it tries to move toward the correct target coordinate, it reaches the right edge of the secondary monitor and disappears — it never actually reaches the intended UI element on the primary monitor.
Steps to Reproduce
Expected behavior:
The pointer hint should appear on the same monitor as the target application and move to the correct UI element.
Actual behavior:
Root Cause Hypothesis
The pointer hint coordinate is likely being calculated correctly in absolute virtual desktop space (e.g.
x: 1980, y: 540targeting the primary monitor), but the overlayBrowserWindowis being created anchored to the secondary monitor's origin instead of the primary.This means the hint's local coordinates within the overlay are offset — the overlay interprets the absolute position relative to the wrong display origin, pushing the hint past the edge of the secondary screen.
Relevant areas to investigate:
renderer/cursor overlay window — check which display the overlayBrowserWindowis being positioned on at creation time.main.js— check ifscreen.getAllDisplays()is used to find the correct display for the active/target window, or if the overlay defaults to display index[1]instead of[0].display.bounds.x,display.bounds.y) must be subtracted, not the secondary display's origin.Suggested Fix
BrowserWindowto be positioned ontargetDisplay.bounds.targetDisplay.boundsto prevent off-screen rendering.Environment
Additional Notes