Description

On macOS, RelativePosition() and SetRelativePosition() disagree about what the X coordinate means:

• RelativePosition() returns the absolute X (NSScreen logical points, not screen-relative)
• SetRelativePosition() treats X as screen-relative (relative to the current screen's left edge)

So w.SetRelativePosition(w.RelativePosition()) does not round-trip on any screen that is not at NSScreen x=0. The Y axis is correctly screen-relative on both sides.

This was flagged by @flofreud while reviewing the coordinate normalization in #5117 / #5304:

Also has a separate inconsistency: Get returns absolute X, Set treats X as screen-relative.

— #5117 (comment)

Expected Behavior

Both RelativePosition() and SetRelativePosition() should operate in the same space. Given the method name and the docstring ("position of the window relative to the screen WorkArea on which it is"), both should be screen-WorkArea-relative, Y-down, in logical points.

Suggested Fix

In pkg/application/webview_window_darwin.go, in the windowGetRelativePosition cgo function, subtract the current screen's frame.origin.x (or visibleFrame.origin.x to match the WorkArea wording) before returning so it mirrors what windowSetRelativePosition consumes.

Notes

• Out of scope for fix(darwin): use primary screen height for SetPosition Y conversion #5304, which is focused on the absolute-position normalization across screens.
• A follow-up should also confirm whether "relative" should be screen-frame-relative or screen-WorkArea-relative — the docstring says WorkArea but the current code uses frame.

Environment

• Wails v3 (pkg/application/webview_window_darwin.go)
• macOS

Related

• [v3, macOS] SetPosition() cannot move windows across screens — Y conversion uses current screen instead of target #5117 — coordinate-system audit that surfaced this
• fix(darwin): use primary screen height for SetPosition Y conversion #5304 — absolute coordinate normalization PR