🐞 Preview.app cannot be resized when targeting the frontmost window (PID -1)

Start by reading WindowUtility.frontmostWindow() in WindowUtility.swift, especially how it handles an invalid NSWorkspace PID and the AXFocusedApplication fallback. Compare that path with the reported CoreGraphics window enumeration and the working cursor-targeting mode. Done means Preview's focused window can be moved or resized with frontmost targeting while other applications continue to work.

Bug Description

Loop fails to move or resize windows in Apple's built-in Preview.app when using the default frontmost/focused-window targeting mode.

When I activate Loop while Preview is focused, the radial menu appears with an exclamation mark (⚠️) instead of the normal action icon. No window preview is displayed, and releasing the shortcut does not move or resize the window.

Loop works normally with other applications.

After investigating the issue through AppleScript, CoreGraphics, and the macOS Accessibility API, I found that the frontmost application lookup returns an invalid PID (-1), while the actual Preview window remains fully accessible through its real PID.

Importantly, enabling "Resize Window Under Cursor" in Loop's settings immediately resolves the issue.

This suggests the problem is related to the frontmost-window discovery path rather than Preview's ability to be resized.

Affected Scope

User interface

Steps to Reproduce

1. Launch Preview.app and open a PDF document.
2. Ensure the PDF window is visible and not in fullscreen mode.
3. Open Loop → Settings → Behavior.
4. Disable Resize Window Under Cursor (use the frontmost/focused window).
5. Focus the Preview window and activate Loop using the configured keyboard shortcut.
6. Attempt to move or resize the window.

Reproducibility

Always

Expected vs Actual Behavior

Expected Behavior

Loop should recognize the focused Preview window and move or resize it according to the selected action, just as it does with other applications.

Actual Behavior

• Loop displays an exclamation mark in the radial menu.
• No window resize preview appears.
• The window remains unchanged.
• Other applications work normally.
• Enabling Resize Window Under Cursor makes Loop work correctly with Preview.

Screen Recordings / Screenshots

No response

Severity

Minor (limited impact)

macOS Version

27.0.1 (26A434)

Loop Version

1.4.2 (1693)

Did You Try the Development Build?

No

Additional Context

Technical Investigation

I investigated the problem using native macOS APIs.

1. NSWorkspace returns an invalid PID

When Preview is the frontmost application:

Frontmost: Preview
NSWorkspace PID: -1

NSWorkspace.shared.frontmostApplication correctly identifies Preview by name, but its processIdentifier is -1.

2. Accessibility fallback fails

Querying the system-wide Accessibility API:

AXFocusedApplication error: -25204

The error corresponds to kAXErrorCannotComplete.

This may be relevant because Loop's WindowUtility.frontmostWindow() appears to use AXFocusedApplication as a fallback when NSWorkspace returns an invalid PID.

3. CoreGraphics can identify Preview's real PID

Enumerating on-screen windows through CGWindowListCopyWindowInfo:

CG window: owner=Preview pid=10243 title=

Preview has a visible window belonging to a valid process (PID 10243 during this test).

4. Direct Accessibility queries succeed with the real PID

I then created an Accessibility application element using the PID obtained from CoreGraphics:

let app = AXUIElementCreateApplication(pid_t(10243))

Results:

Preview window PIDs: [10243]
AXWindows: error=0, exists=true
AXFocusedWindow: error=0, exists=true
AXMainWindow: error=0, exists=true

All three Accessibility queries succeed.

This confirms that Preview's window is accessible when addressed using its actual PID.

5. Additional AppleScript tests

Preview's own AppleScript interface:

tell application "Preview" to count windows

Result:

1

However, System Events reports:

tell application "System Events"
    tell process "Preview"
        return {frontmost, count of windows, name of every window}
    end tell
end tell

Result:

true, 0,

After correcting Terminal's Accessibility permissions, a comparison test against Finder successfully returned two windows.

This indicates a discrepancy between Preview's own window enumeration and the window information exposed through System Events.

Confirmed Workaround

Enabling the following setting fixes the problem:

Loop → Settings → Behavior → Resize Window Under Cursor → ON

After enabling this setting, Loop successfully detects and resizes Preview windows when the cursor is positioned over them.

Disabling the setting restores the original failure.

This is the most useful finding from the investigation, since it isolates the issue to a particular target-window discovery mode.

Possible Root Cause

Based on Loop's source code, the issue may involve:

WindowUtility.frontmostWindow() in WindowUtility.swift

The current implementation obtains the frontmost application using NSWorkspace.shared.frontmostApplication.

When its PID is invalid (<= 0), it falls back to querying the system-wide AXFocusedApplication attribute.

In my environment, both approaches fail for Preview:

• NSWorkspace PID: -1
• AXFocusedApplication: -25204

However, CoreGraphics can identify Preview's actual PID, and direct Accessibility queries using that PID succeed.

It may be worth investigating whether an additional fallback could retrieve the PID from the frontmost on-screen window using CoreGraphics or another reliable window-discovery mechanism.

I cannot yet determine why macOS returns these unexpected results specifically for Preview, so this may involve an OS-level issue as well as an opportunity to improve Loop's resilience.

Relevant source:
https://github.com/MrKai77/Loop/blob/develop/Loop/Window%20Management/Window/WindowUtility.swift

Environment

• macOS Version: 27.0.1 (26A434)
• Loop Version: 1.4.2 (1693)
• Affected Application: Apple Preview.app
• Reproducibility: Consistent during testing
• Other Applications: Working normally
• Workaround: Enable "Resize Window Under Cursor"

Additional Notes

I initially suspected an Accessibility permissions issue, but after correcting Terminal's permissions and testing the native AX API directly, the Preview window could be accessed successfully using its actual PID.

The issue appears specifically related to discovering the target window through the frontmost-application path.

I hope the diagnostic results are useful. Please let me know if additional logs or tests would help identify the cause.

Final Checks

• My issue is written in English.
• My issue title is descriptive.
• This is a single bug (multiple bugs should be reported individually).
• I have looked to see if this is a duplicate of another bug report.
• I can help with further investigation.
• I can help with developing a fix for this issue.