🐞 Malfunction In Window Movement When "Use macOS Window Manager When Available" Is Enabled

[AlejandroVolkova]

Bug Description

I have identified a functionality issue when using the option "Use macOS window manager when available."
When this option is enabled, "Resize window under cursor" does not operate correctly, resulting in failures when moving windows.

• The attached video demonstrates that Loop fails to move the window directly under the cursor.
• At times, the wrong window «one not under the cursor» is the one that gets moved.
• I think this issue might originate because Loop fails to bring the window under the cursor to the front before attempting to move it.

Affected Scope

User interface

Steps to Reproduce

1. Enable the option "Use macOS window manager when available."
2. Attempt to use "Resize window under cursor."
3. Observe the behavior when trying to move a window under the cursor.

Reproducibility

Often (≥70%)

Expected vs Actual Behavior

• Loop fails to move the window under the cursor.
• In some cases, a different window is moved instead.

Screen Recordings / Screenshots

Loop.Issue.mp4

Severity

Major (workaround exists)

macOS Version

Tahoe 26.2

Loop Version

Version 🧪 1.4.0 (1652)

Did You Try the Development Build?

Yes

Additional Context

Workaround

• Disabling the option "Use macOS window manager when available" prevents the issue from occurring.

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.

[mrkai77]

I’m able to reproduce this. It seems to only occur when both windows belong to the same app, and while investigating, I also found another bug: if the “Focus window on resize” toggle is disabled, it fails 100% of the time 😅

I think this issue might originate because Loop fails to bring the window under the cursor to the front before attempting to move it.

You are correct about this, will look into this issue!

[AlejandroVolkova]

Thank you :)

It seems to only occur when both windows belong to the same app

I didn't notice before, but after testing, I can confirm that in my environment this is also the case 😄, and the other bug is true as well.

[mrkai77]

Will be fixed in the next developer build!