Bug: Selected window capture is overridden; focus forcefully returns to Recordly

[rohan-prasen]

Version: recordly-v1.3.3-macOS
Platform: ARM64-macOS

Summary

When selecting a specific window to capture, the active/focused window is automatically forced back to Recordly. As a result, the intended target window (e.g., browser with simulator) loses focus, and interactions in that window are partially blocked or non-functional.

Steps to Reproduce

1. Open Recordly (v1.3.3 on macOS).

2. Open another app window (example: browser running a simulator).

3. In Recordly, choose Window Capture and select that target window.

4. Start recording.

5. Try interacting with controls/buttons in the selected target window.

Expected Behavior

• The selected target window should remain interactive and usable during capture.

• Recordly should not forcibly take primary focus after recording starts.

• Buttons and controls in the target window should work normally.

Actual Behavior

• Recordly becomes/keeps the primary active window.

• Focus gets “stuck” on Recordly even after selecting another window for capture.

• Some buttons in the target window do not respond or cannot be clicked as expected.

Reproducibility

• Consistently reproducible (or: frequently reproducible).

Impact

• Prevents reliable demos/tutorial recordings of interactive apps/simulators.

• Breaks user workflows where target-window interaction is required during recording.

Workarounds Tried

• Re-selecting the window after recording start.

• Clicking back into the target window manually.(If these didn’t work, keep this as-is; if you tried others, add them.)

Additional Notes

• This appears to be a focus/foreground-window management issue during window-capture mode on macOS.

• If useful, I can provide a screen recording showing focus being pulled back to Recordly.