Floating windows are disappearing often when moving between workspaces. #1875
Replies: 12 comments 26 replies
-
|
I also see my floating windows (bitwarden and apple music are two examples) which can "disappear" (AS moved them offscreen but they don't come back). My solution to this uses BetterTouchTool which can resize/place floating windows bound to a single key to bring the window onscreen (though probably your solution of float>tile>float can be tapped very fast also). Having a feature like #633 built-in would solve this hard to reproduce bug without external dependencies, but at least for me as I use BTT anyway this is not an issue. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I'm not familiar with BTT, I'll look at it to see if it can help. my problem is that it's not a single floating window in a workspace that I can easily see that it disappeared. I may have multiple overlapping floating windows in this workspace, and I'll scroll through most of them, until I figure out that the one I'm looking for is missing, then I have to search for it in alt-tab which doesn't show screenshot of windows outside the viewable area (or navigate to the window through other means, both option takes a long time), and only then do I get to run the shortcut to bring it back. I'm also not sure #633 relates to my problem, I'm using floating windows by default (or have I misunderstood the problem?). |
Beta Was this translation helpful? Give feedback.
-
|
I almost don't use floating windows, so this issue is tricky for me to reproduce How many monitors do you have? I vaguely remember that there is some bug around that incorrectly places floating windows in the corner when external monitors disconnected or something If you are up to adventure of debugging the problem yourself, you can start with the following logging patch: diff --git a/Sources/AppBundle/tree/MacWindow.swift b/Sources/AppBundle/tree/MacWindow.swift
index bd702c0e..af3fc583 100644
--- a/Sources/AppBundle/tree/MacWindow.swift
+++ b/Sources/AppBundle/tree/MacWindow.swift
@@ -154,6 +154,7 @@ final class MacWindow: Window {
@MainActor
func unhideFromCorner() {
+ print("unhideFromCorner for: \(windowId). \(prevUnhiddenProportionalPositionInsideWorkspaceRect). \(nodeWorkspace). \(parent)")
guard let prevUnhiddenProportionalPositionInsideWorkspaceRect else { return }
guard let nodeWorkspace else { return } // hiding only makes sense for workspace windows
guard let parent else { return }
@@ -167,6 +168,7 @@ final class MacWindow: Window {
x: workspaceRect.width * prevUnhiddenProportionalPositionInsideWorkspaceRect.x,
y: workspaceRect.height * prevUnhiddenProportionalPositionInsideWorkspaceRect.y,
)
+ print("unhideFromCorner. floatingWindow. for: \(windowId). pointInsideWorkspace: \(pointInsideWorkspace). workspaceRect: \(workspaceRect)")
setAxFrame(workspaceRect.topLeftCorner + pointInsideWorkspace, nil)
case .macosNativeFullscreenWindow, .macosNativeHiddenAppWindow, .macosNativeMinimizedWindow,
.macosPopupWindow, .tiling, .rootTilingContainer, .shimContainerRelation: break |
Beta Was this translation helpful? Give feedback.
-
|
@nikitabobko, before I start I just wanted to ask (I have no experience in desktop development on mac). I see in |
Beta Was this translation helpful? Give feedback.
-
Just for the record: I remembered the bug #1492 and it was fixed so I don't think it's the cause |
Beta Was this translation helpful? Give feedback.
-
If you only plan to build the debug version of AeroSpace, you can run it from the terminal and custom certificate is not required. (it's mentioned in |
Beta Was this translation helpful? Give feedback.
-
|
Sorry @nikitabobko , but it took me a while until I had time to set it up. The entire output is quite large (180k) so I copied just some lines that involves the window that actually disappeared. Let me know if you need me to run something else: Thanks |
Beta Was this translation helpful? Give feedback.
-
|
For me the same problem happens on a single monitor. I constantly find floating windows disappearing when switching to them after some time (like 1 day). So the problem is not limited to dual monitors setups. |
Beta Was this translation helpful? Give feedback.
-
|
I see them sometimes in the lower right/left corner very small, not sure if this is a related issue. I then resize them and bring them to the center of the screen. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I'm not sure it's the same issue because when I toggle tile > float, they are back to the original size. |
Beta Was this translation helpful? Give feedback.
-
|
same issue as well, I can see them in the corner but it is a struggle to select them and toggle float and tile, sometimes it happens even to tiled apps, my only solution is to restart aerospace and then i can see them and select them |
Beta Was this translation helpful? Give feedback.
-
|
I don't know if this helps at all but I use When this happens to me, I use aerospace to focus the window so I see the border around the app window in corner of my screen. I think you should then be able tile the window so it jumps out of the corner and then re-float it. I use Rectangle and I have a shortcut to center windows so I use that to get it out of the corner; however, I'd like to think the float->tile->float approach would also work without having to restart aerospace. |
Beta Was this translation helpful? Give feedback.
-
|
I think I'm also seeing this issue since upgrading to 0.20.0-Beta. I think (at least for me) the issue is related to locking the screen and leaving the machine for a while. On unlocking, the floating windows aren't restored when switching to the workspaces they belong to. It's not every time but that might be due to timings of the steps above; if they have an impact at at all and it's not just random. I don't think (or at least remember) the floating windows not restoring when using the machine without locking. I have a laptop + main monitor setup. The workspaces on the Laptop are all set to tile/accordion. On the main monitor, I have a few workspaces where I use floating windows. I don't disconnect/connect the laptop from the monitor very often and this issue definitely occurs whilst they have remained connected. The Laptop is connected to a dock, and the main monitor to the dock. When the issue occurs the floating window is in the bottom-right of the main monitor (the aerospace hideout). If I use the |
Beta Was this translation helpful? Give feedback.
-
|
Does the floating window reappear if you spam |
Beta Was this translation helpful? Give feedback.
-
|
I'll give it a try once it happens again. |
Beta Was this translation helpful? Give feedback.
-
|
Just had it happen. Tried spamming |
Beta Was this translation helpful? Give feedback.
-
|
Cross reference: #1483 |
Beta Was this translation helpful? Give feedback.
-
|
I have the same issue |
Beta Was this translation helpful? Give feedback.
-
|
I have the same problem:
|
Beta Was this translation helpful? Give feedback.
-
|
Does you computer sleep / lock? This certainly seems to be the trigger for me and several others? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it does lock and the issue happens exactly after unlocking it. So it's the same issue here |
Beta Was this translation helpful? Give feedback.
-
|
I must say that for me, it happens in mid work,, I don't see special connection to locking. I do have two monitors. |
Beta Was this translation helpful? Give feedback.
-
|
At first I thought I'd seen it only on unlocking machine but I have since seen it mid work when switching between workspaces. |
Beta Was this translation helpful? Give feedback.
-
|
I meet this problem too so an strange app which does not appear in config file will open in folat layout, and this kind of app always hide in the left bottom corner , it's hard to make it appear again. |
Beta Was this translation helpful? Give feedback.
-
|
I also encounter this issue daily. The problem appears:
As a workaround I use Raycast's windows management to center the window which will make it reappear. |
Beta Was this translation helpful? Give feedback.
-
|
I’m seeing the same issue. Floating windows sometimes end up in the bottom-right corner (effectively off-screen) after my computer has been idle for a while. I’m on a single Samsung Odyssey G9 (49″ ultrawide). Because single tiled windows get impractically wide, I float certain windows in specific workspaces. When this happens, those floating windows become hidden until I manually move them back or restart the app. It would also be really helpful to have a way to center a single window in a workspace with gaps on the sides, so floating isn’t required just to avoid overly wide layouts. |
Beta Was this translation helpful? Give feedback.
-
|
I'm able to consistently replicate this issue by doing the following:
Usually I have to alt+tab around 15 times for the finder window to disappear, but sometimes it only takes a few alt+tabs. I'm not sure if this is useful, but I ran debug-windows before and after the finder window disappears, and it showed that the x value of AXPosition/frame/etc increases by 1215, while the y value increases by 640. I am on a macbook with no external monitors. |
Beta Was this translation helpful? Give feedback.
-
|
I played around a bit and also moved the diff --git i/Sources/AppBundle/tree/MacWindow.swift w/Sources/AppBundle/tree/MacWindow.swift
index bd702c0e..60cbee44 100644
--- i/Sources/AppBundle/tree/MacWindow.swift
+++ w/Sources/AppBundle/tree/MacWindow.swift
@@ -134,6 +134,7 @@ final class MacWindow: Window {
let absolutePoint = topLeftCorner - monitorRect.topLeftCorner
prevUnhiddenProportionalPositionInsideWorkspaceRect =
CGPoint(x: absolutePoint.x / monitorRect.width, y: absolutePoint.y / monitorRect.height)
+ print("hideInCorner for: \(windowId). \(prevUnhiddenProportionalPositionInsideWorkspaceRect). \(nodeWorkspace). \(parent) \(absolutePoint) \(topLeftCorner) \(windowRect)")
}
let p: CGPoint
switch corner {
@@ -157,6 +158,7 @@ final class MacWindow: Window {
guard let prevUnhiddenProportionalPositionInsideWorkspaceRect else { return }
guard let nodeWorkspace else { return } // hiding only makes sense for workspace windows
guard let parent else { return }
+ print("unhideFromCorner for: \(windowId). \(prevUnhiddenProportionalPositionInsideWorkspaceRect). \(nodeWorkspace). \(parent)")
switch getChildParentRelation(child: self, parent: parent) {
// Just a small optimization to avoid unnecessary AX calls for non floating windows
@@ -167,6 +169,7 @@ final class MacWindow: Window {
x: workspaceRect.width * prevUnhiddenProportionalPositionInsideWorkspaceRect.x,
y: workspaceRect.height * prevUnhiddenProportionalPositionInsideWorkspaceRect.y,
)
+ print("unhideFromCorner. floatingWindow. for: \(windowId). pointInsideWorkspace: \(pointInsideWorkspace). workspaceRect: \(workspaceRect)")
setAxFrame(workspaceRect.topLeftCorner + pointInsideWorkspace, nil)
case .macosNativeFullscreenWindow, .macosNativeHiddenAppWindow, .macosNativeMinimizedWindow,
.macosPopupWindow, .tiling, .rootTilingContainer, .shimContainerRelation: breakI observed that The packs of 4 log statements visualize the workspace change. For me there are 2 questions:
|
Beta Was this translation helpful? Give feedback.
-
|
A git bisect analysis shows me that the following commit introduced the issue So this might be a concurrency bug. This would explain log traces like this: that would not make sense otherwise (an diff --git i/Sources/AppBundle/layout/refresh.swift w/Sources/AppBundle/layout/refresh.swift
index 56603a90..72e4080d 100644
--- i/Sources/AppBundle/layout/refresh.swift
+++ w/Sources/AppBundle/layout/refresh.swift
@@ -181,9 +181,12 @@ private func layoutWorkspaces() async throws {
workspace.allLeafWindowsRecursive.forEach { ($0 as! MacWindow).unhideFromCorner() } // todo as!
try await workspace.layoutWorkspace()
}
+ print("layoutWorkspaces")
for workspace in Workspace.all where !workspace.isVisible {
+ print("outter \(workspace.description)")
let corner = monitorToOptimalHideCorner[workspace.workspaceMonitor.rect.topLeftCorner] ?? .bottomRightCorner
for window in workspace.allLeafWindowsRecursive {
+ print("inner \(workspace.description) \(window)")
try await (window as! MacWindow).hideInCorner(corner) // todo as!
}
} |
Beta Was this translation helpful? Give feedback.
-
|
Thank you @fbuetler for these insightful comments, I agree that the issue seems to be related to concurrency. Here is one possible explanation:
This would explain why this issue does not occur regularly, since if call 2 reads the value of windowRect before the window is repositioned in call 2, then it will still save the correct unhidden position of the window. To confirm this, I added a check in diff --git a/Sources/AppBundle/tree/MacWindow.swift b/Sources/AppBundle/tree/MacWindow.swift
index bd702c0e..dabb8765 100644
--- a/Sources/AppBundle/tree/MacWindow.swift
+++ b/Sources/AppBundle/tree/MacWindow.swift
@@ -129,11 +129,17 @@ final class MacWindow: Window {
// `hideEmulation` calls
if !isHiddenInCorner {
guard let windowRect = try await getAxRect() else { return }
+ // Another concurrent hide call may have already captured the original position.
+ if isHiddenInCorner {
+ print("hideInCorner skipped because window is already hidden: \(windowId)")
+ return
+ }
let topLeftCorner = windowRect.topLeftCorner
let monitorRect = windowRect.center.monitorApproximation.rect // Similar to layoutFloatingWindow. Non idempotent
let absolutePoint = topLeftCorner - monitorRect.topLeftCorner
prevUnhiddenProportionalPositionInsideWorkspaceRect =
CGPoint(x: absolutePoint.x / monitorRect.width, y: absolutePoint.y / monitorRect.height)
+ print("hideInCorner for: \(windowId). \(prevUnhiddenProportionalPositionInsideWorkspaceRect). \(nodeWorkspace). \(parent) \(absolutePoint) \(topLeftCorner) \(windowRect)")
}
let p: CGPoint
switch corner {
@@ -157,6 +163,7 @@ final class MacWindow: Window {
guard let prevUnhiddenProportionalPositionInsideWorkspaceRect else { return }
guard let nodeWorkspace else { return } // hiding only makes sense for workspace windows
guard let parent else { return }
+ print("unhideFromCorner for: \(windowId). \(prevUnhiddenProportionalPositionInsideWorkspaceRect). \(nodeWorkspace). \(parent).")
switch getChildParentRelation(child: self, parent: parent) {
// Just a small optimization to avoid unnecessary AX calls for non floating windows
@@ -167,6 +174,7 @@ final class MacWindow: Window {
x: workspaceRect.width * prevUnhiddenProportionalPositionInsideWorkspaceRect.x,
y: workspaceRect.height * prevUnhiddenProportionalPositionInsideWorkspaceRect.y,
)
+ print("unhideFromCorner. floatingWindow. for: \(windowId). pointInsideWorkspace: \(pointInsideWorkspace). workspaceRect: \(workspaceRect)")
setAxFrame(workspaceRect.topLeftCorner + pointInsideWorkspace, nil)
case .macosNativeFullscreenWindow, .macosNativeHiddenAppWindow, .macosNativeMinimizedWindow,
.macosPopupWindow, .tiling, .rootTilingContainer, .shimContainerRelation: break
This seems to resolve the issue for me, so I would be happy to hear from others who are having the same problem if this fixes it; if so, I can submit a pr. The log statements also show that now one of the There is still one thing that is confusing me: I was also able to prevent the problem occurring (at least for the few times I tested it) by moving the diff --git a/Sources/AppBundle/tree/MacWindow.swift b/Sources/AppBundle/tree/MacWindow.swift
index bd702c0e..96d52251 100644
--- a/Sources/AppBundle/tree/MacWindow.swift
+++ b/Sources/AppBundle/tree/MacWindow.swift
@@ -168,11 +168,10 @@ final class MacWindow: Window {
y: workspaceRect.height * prevUnhiddenProportionalPositionInsideWorkspaceRect.y,
)
setAxFrame(workspaceRect.topLeftCorner + pointInsideWorkspace, nil)
+ self.prevUnhiddenProportionalPositionInsideWorkspaceRect = nil
case .macosNativeFullscreenWindow, .macosNativeHiddenAppWindow, .macosNativeMinimizedWindow,
.macosPopupWindow, .tiling, .rootTilingContainer, .shimContainerRelation: break
}
-
- self.prevUnhiddenProportionalPositionInsideWorkspaceRect = nil
}
override var isHiddenInCorner: Bool {This suggests that at some point, the floating window adopts a |
Beta Was this translation helpful? Give feedback.
-
|
Also: the latter fix (only reset |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for investigating further! I can confirm the first patch, also fixes the issue for me. However, I think it is a suboptimal solution is it only makes the issue occur less frequent, but it still exists. I'd rather suggest to use something like AtomicReference for Regarding the second patch, I also don't understand why this would fix the issue. But it with it, I also cannot reproduce the issue. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Body
Hi,
I work with about 50% floating windows and I probably encounter problems that other users don't...
A few times a day, when moving between workspaces, floating windows disappear (I guess moved outside the viewable area). In order to see them again I have to:
It started a few weeks ago (don't remember exactly when as I'm not working on mac daily) and about the time it started, I updated both MacOS (Tahoe - 26.1) and AeroSpace itself.
Steps to reproduce: Work for a while with many floating windows on multiple workspaces, it should happen within a couple of hours.
Expected result: All floating windows in a workspace should be visible
Additional info
Thanks
Beta Was this translation helpful? Give feedback.
All reactions