Summary
Restoring the ESPHome layout from an empty macOS Space unexpectedly changes to another Space and restores the layout there. This breaks the expected “restore into the current Space” behavior.
Steps to reproduce
- Create at least two user Spaces on the same display.
- Save a Settle layout named ESPHome containing its application windows.
- Move to another Space that has no windows.
- Restore the ESPHome layout from Settle.
Actual behavior
macOS switches away from the empty Space—typically to one where an ESPHome-related application already has windows—and the layout is restored there.
Expected behavior
The active Space at the time of restore must remain selected:
- The empty Space stays selected.
- Missing windows are created or moved into that Space without activating another one.
- Existing windows in other Spaces do not cause Settle to navigate away.
- If placement in the current Space is impossible, Settle reports the affected window instead of silently changing Spaces.
Impact
Users cannot rely on an empty Space as a clean destination for a saved layout; restoration unexpectedly changes their desktop context.
Investigation
The restore path only searches for windows visible in the current Space. When a window is missing, it invokes the target app’s “New Window” accessibility action and, as a fallback, reopens the app. Either can make macOS activate the Space containing that app’s existing windows. The flow has no invariant or post-action check to keep the initiating Space selected.
The layout model declares a currentSpaceOnly policy, so this behavior contradicts the policy’s name and user expectation.
Acceptance criteria
- Restoring from an empty Space does not change the active Space.
- The case works when the target app has windows in another Space.
- Add a regression test for the Space-retention invariant where feasible, plus a documented manual test for macOS Space switching.
- Failures to create or place a window in the current Space appear in the restore report.
Environment
- Settle version: 1.12.0
- macOS desktop with multiple Spaces
- Layout: ESPHome
Evidence
A screenshot supplied with this report shows ESPHome selected in Settle from an empty Space.
Verification note
I reviewed the restore flow and built the test target. An independent end-to-end Space-switching run could not be completed here because macOS blocks the test runner’s desktop-service communication; this is recorded as a user-observed bug, with the likely triggering path documented above.
Summary
Restoring the ESPHome layout from an empty macOS Space unexpectedly changes to another Space and restores the layout there. This breaks the expected “restore into the current Space” behavior.
Steps to reproduce
Actual behavior
macOS switches away from the empty Space—typically to one where an ESPHome-related application already has windows—and the layout is restored there.
Expected behavior
The active Space at the time of restore must remain selected:
Impact
Users cannot rely on an empty Space as a clean destination for a saved layout; restoration unexpectedly changes their desktop context.
Investigation
The restore path only searches for windows visible in the current Space. When a window is missing, it invokes the target app’s “New Window” accessibility action and, as a fallback, reopens the app. Either can make macOS activate the Space containing that app’s existing windows. The flow has no invariant or post-action check to keep the initiating Space selected.
The layout model declares a
currentSpaceOnlypolicy, so this behavior contradicts the policy’s name and user expectation.Acceptance criteria
Environment
Evidence
A screenshot supplied with this report shows ESPHome selected in Settle from an empty Space.
Verification note
I reviewed the restore flow and built the test target. An independent end-to-end Space-switching run could not be completed here because macOS blocks the test runner’s desktop-service communication; this is recorded as a user-observed bug, with the likely triggering path documented above.