Closed windows still occupy space after updating to Sequoia

[ChristianK43]

Description

After updating to Sequoia, I've encountered a problem where closed windows continue to occupy space and are treated as if they're still open. This issue persists in both the latest release and the latest git version.
SIP disabled as per guide.

Question

Has anyone else encountered this issue since updating to Sequoia? Any known workarounds or solutions?

Edit: attached a video of it. When i kill the process of the application the windows belong to, they stop occupying the space.

Screen.Recording.Sept.19.mp4

[liam-mackie]

I'm having this issue, and I captured the debug logs associated. Note that the iTerm2 is me changing the config:

EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 638
EVENT_HANDLER_MOUSE_DOWN: 2483.85, 1423.93
EVENT_HANDLER_APPLICATION_LAUNCHED: Messages (29733) is not finished launching, subscribing to finishedLaunching changes
-[workspace_context observeValueForKeyPath:ofObject:change:context:]: Messages (29733) finished launching
EVENT_HANDLER_APPLICATION_LAUNCHED: Messages (29733)
window_manager_create_and_add_window:709 Messages - <REDACTED> (AXWindow:AXStandardWindow:1)
EVENT_HANDLER_APPLICATION_FRONT_SWITCHED: Messages (29733)
EVENT_HANDLER_WINDOW_RESIZED: Arc 497
EVENT_HANDLER_WINDOW_RESIZED: Arc 498
EVENT_HANDLER_WINDOW_MOVED:DEBOUNCED Arc 498
EVENT_HANDLER_DAEMON_MESSAGE: query --windows
EVENT_HANDLER_DAEMON_MESSAGE: query --windows
EVENT_HANDLER_MOUSE_DOWN: 3443.49, 64.40
EVENT_HANDLER_MOUSE_DRAGGED: 3443.26, 64.17
EVENT_HANDLER_MOUSE_DRAGGED: 3443.03, 64.17
EVENT_HANDLER_MOUSE_UP: 3443.03, 64.17
EVENT_HANDLER_MOUSE_DOWN: 2498.48, 1418.57
window_manager_create_and_add_window:713 Messages - <REDACTED> (AXWindow:AXStandardWindow:1)
EVENT_HANDLER_WINDOW_FOCUSED: Messages 713
EVENT_HANDLER_WINDOW_RESIZED: Arc 497
EVENT_HANDLER_WINDOW_RESIZED: Arc 498
EVENT_HANDLER_WINDOW_MOVED:DEBOUNCED Arc 498
EVENT_HANDLER_WINDOW_RESIZED: Messages 713
EVENT_HANDLER_WINDOW_MOVED:DEBOUNCED Messages 713
EVENT_HANDLER_DAEMON_MESSAGE: query --windows
EVENT_HANDLER_DAEMON_MESSAGE: query --windows
EVENT_HANDLER_MOUSE_DOWN: 4315.27, 705.62
EVENT_HANDLER_MOUSE_DRAGGED: 4315.27, 705.85
EVENT_HANDLER_MOUSE_DRAGGED: 4315.27, 706.30
EVENT_HANDLER_MOUSE_UP: 4315.27, 706.30
EVENT_HANDLER_APPLICATION_FRONT_SWITCHED: Arc (15056)
EVENT_HANDLER_APPLICATION_TERMINATED: Messages (29733)
EVENT_HANDLER_WINDOW_RESIZED: Arc 497
EVENT_HANDLER_WINDOW_RESIZED: Arc 498
EVENT_HANDLER_WINDOW_MOVED:DEBOUNCED Arc 498
EVENT_HANDLER_DAEMON_MESSAGE: query --windows
EVENT_HANDLER_MOUSE_DOWN: 1338.07, 211.95
EVENT_HANDLER_MOUSE_DRAGGED: 1338.07, 211.71
EVENT_HANDLER_MOUSE_UP: 1338.07, 211.71
EVENT_HANDLER_WINDOW_TITLE_CHANGED: iTerm2 638
EVENT_HANDLER_DAEMON_MESSAGE: config debug_output off

In this reproduction, I:

1. Opened iMessage
   • This worked as per normal
2. Closed the iMessage window
   • The bug as described happened here, and the space was still seen as occupied even though the window was no longer open.
3. Opened iMessage again
   • The window opened according to my normal window partitioning, though it treated the empty space as a window
4. Quit iMessage
   • This removed the window and the blank space that wasn't meant to be there

[koekeishiya]

If you are using Contexts, that is the reason: #2324 (comment)

If not, I have no idea -- works for me on Sequoia.

[liam-mackie]

Dang, you're right, it was Contexts for me. Thanks for the tip!

[ChristianK43]

I do not use Contexts, but the tip lead me to check all running applications and i could identify AmazonQ as the culprit in my case. Thanks for the help!

[koekeishiya]

Published a compatibility workaround/fix in v7.1.4.