Looping/Bouncing Between Workspaces

[NicholasFields]

Context:

❯ aerospace -v
aerospace CLI client version: 0.12.0-Beta 9cf82fe
AeroSpace.app server version: 0.12.0-Beta 9cf82fe

[issue was present in earlier versions, I believe]

Repro:

• Number of monitors must be > 1

• Open 2 instances of Chrome. To ensure it wasn't some chrome config, I used two incognito windows this AM.

• Place Chrome instance # 1 on workspace A

• Place Chrome instance # 2 on workspace B

• Switch back and forth between the workspaces

For me, within a few switches, a "workspace switching loop" will initiate.
By this, I mean:

Aerospace will automatically switch from workspace A => workspace B => workspace A => workspace B and so on.
In a rapid, flicker pattern.

Other notes:

To end the behavior, I usually just send command for the target workspace repetitively.
This tends to break the loop.

---

Let me know if you need anything else --
Thanks for AeroSpace!

[adamdottv]

also running into this! loving aerospace, btw

[LeandroLovisolo]

Having the same issue! I'm running the same version as the OP.

[nikitabobko]

The issue sounds suspicious. I couldn't reproduce it

• Is it reproducible only with Chrome windows?
• Do workspaces A and B must be on different monitors?
• You use workspace-back-and-forth command to switch between workspaces, right?

I even tried this script to emulate quick initial workspace switches:

aerospace focus --window-id 13305 # chrome window 1
aerospace focus --window-id 16745 # chrome window 2
for i in $(seq 1 50); do
    sleep 0.01
    aerospace workspace-back-and-forth
done

[NicholasFields]

definitely sus -- as the kids say.

Is it reproducible only with Chrome windows?

• Yes, as far as I am aware. I've been wondering if Chrome has some "hold on to focus" effect?

Do workspaces A and B must be on different monitors?

• Nope. I must have > 1 monitor. But workspaces A and B themelves can be on the same monitor - or on two distinct monitors.

You use workspace-back-and-forth command to switch between workspaces, right?

• I'm using simple workspace commands, e.g., I press alt-u to trigger the workspace u command stored in my config as alt-u = 'workspace U'

I even tried this script to emulate quick initial workspace switches:

• Speed of switching doesn't seem to be causal.

---

A bit more context from re-inducing the problem just now:
I'm using JankyBorders.

• May require a full 3 monitors (@adamdottv, @LeandroLovisolo -- please report your # of monitors // if you can repro on only 2)
• I have one Chrome window on workspace u.
• Second Chrome on workspace t.
• The very-first-time I navigate from workspace u to workspace t by pushing alt-u, the Chrome window on workspace u is shown. However, it lacks the blue (active window) padding from JankyBorders.

In other words, on the-very-first-switch to a chrome window, it is (perhaps) never fully focus'd.

Then:
on the switch to the other chrome window via alt-t,
the flickering ensues.

[LeandroLovisolo]

May require a full 3 monitors (@adamdottv, @LeandroLovisolo -- please report your # of monitors // if you can repro on only 2)

I'm on a Macbook Pro with only one external display, so 2 displays total.

[NicholasFields]

Thanks @LeandroLovisolo - I was also able to rerpo on just 2 monitors.

Also, here's a vid repro. Note that I don't use the mouse at all during the vid. Only the keys shown by KeyCastr.

aerospace-chrome-flicker.mp4

[LeandroLovisolo]

Also, here's a vid repro.

Yep, that's exactly what I see!

[adamdottv]

Also, here's a vid repro.

Yep, that's exactly what I see!

Same! I'm using a Mac Studio with two monitors.

[wtianyi]

I'm experiencing the same / similar looping problem. It seems what happens to me is that

1. One workspace (A) containing one or more Chrome windows is on my (one and only) external display, visible, but none of the windows is active (i.e. their window control buttons are all gray; this seems to be necessary)
2. Another workspace (B) on the same external display is hidden, i.e. all of its windows are stashed at the corner of the main display.
3. Under certain condition that I haven't completely figured out, when switching to workspace B (either via Aerospace hotkey, or activating one of its Chrome windows with ⌘-Tab or Mission Control),
   1. The focus first goes to a Chrome window in B (i.e. it becomes an active window, with colored window control buttons), and all windows in B are moved to the external display, in the mean time all windows in A are moved to the corner of the main display
   2. Right after that, mysteriously, a window in A gets activated (its window control buttons get colored), and workspace A is also activated and moved back to the external display, and B again stashed to the corner of the main display. I'm guessing that the weird re-focus to a window in A is due to Chrome. Now workspace A takes the external display.
   3. Instantly, a window in B gets (mysteriously) activated, and brings B to the external display and puts A windows away
   4. The back-and-forth switch loop keeps on

More notes:

1. The loop is not always self-sustainable, in rare cases, things stabilize after several flickers

2. A strange Chrome window (re-)focus behavior that might be relevant: If there is a Chrome window in a third workspace (C), and the workspace configuration is

   • A: assigned to external display; all windows are not active, but visible on the external display
   • B: assigned to external display; all windows are not active, and are on the corner of the main display
   • C: assigned to main display; a Chrome window is active, let's call it window γ

   Now if I

   1. First switch to some other non-Chrome window (say a Finder window) in C
   2. Then activate to workspace B

   Workspace B is successfully put to the external display, but all of its windows are not active (control buttons grayed out). The active window, surprisingly, becomes the window γ, and not the Finder window.

[mikeborodin]

I got the same I thing

[nikitabobko]

Surprised to see 9 votes on the issue. Apparently, something major got broken, but I still can't reproduce the problem.

People started coming only after 0.12.0-Beta. Is the problem reproducible in 0.11.2-Beta?

By looking at changelog between 0.11.2-Beta and 0.12.0-Beta v0.11.2-Beta...v0.12.0-Beta the only suspicious commit that could cause the problem is 588f697

I'd appreciate if somebody who has this problem could try to revert the commit and build from sources to see if it helps. Or otherwise try to bisect the problem between 0.11.2-Beta and 0.12.0-Beta. I assume that it's a 0.12.0 regression, so we need to confirm that first

[tuzemec]

Weird... I can replicate this but only with Chrome and with at least one external monitor (on a MBP).
Tried a bunch of other apps - Safari, Firefox, Zed, Sublime, VSCode, Arc... they all work as expected.

Is there an easy way to downgrade to 0.11.2 and test?

[nikitabobko]

@tuzemec Download .zip from GH releases page and install it manually. You don't even need to install it, you can just run .app directly from unpacked zip

[tuzemec]

For me 0.11.2-beta works fine, without this bouncing between the workspaces.

There's some very rare cases when it doesn't switches to the new workspace with Chrome at first, but if I press the shortcut again - it works. Can't find any logic or ways to reproduce that, so I'm willing to ignore it :)

[nikitabobko]

Then I'd appreciate if somebody who has this problem reproducible to "git bisect" the bug in the v0.11.2-Beta...v0.12.0-Beta range

I'd start by reverting 588f697

[xuyixin1996]

Then I'd appreciate if somebody who has this problem reproducible to "git bisect" the bug in the v0.11.2-Beta...v0.12.0-Beta range

I'd start by reverting 588f697

The issue persists in latest beta version (0.13.3-Beta) and I can reproduce the issue in my laptop with external display plugged

❯ aerospace list-monitors
1 | DELL U2720Q
2 | Built-in Retina Display

when assigning 2 different chrome window into workspace 1 and workspace 2 and mauanlly switch between workspace few times (press option+1, option+2, option+1, and repeat), the issue appears.

❯ aerospace list-windows --all --format '%{app-name}|%{workspace}'
Alacritty|4
Google Chrome|1
Google Chrome|2

One side note that if two chrome windows are in the same workspace and only move focus between two windows, no looping/bouncing/flickering happens.

--- Update
I follow the devleoper guide and run the debug mode in my laptop to reproduce the issue, here is the output

hideViaEmulation: Hide Window(title: 'Optional("New Incognito tab - Google Chrome (Incognito)")', role: 'Optional("AXWindow")', subrole: 'Optional("AXStandardWindow")', identifier: 'nil', modal: 'Optional("false")', windowId: 'Optional("31067")')
hideViaEmulation: Hide Window(title: 'Optional("New Incognito tab - Google Chrome (Incognito)")', role: 'Optional("AXWindow")', subrole: 'Optional("AXStandardWindow")', identifier: 'nil', modal: 'Optional("false")', windowId: 'Optional("31063")')
hideViaEmulation: Hide Window(title: 'Optional("New Incognito tab - Google Chrome (Incognito)")', role: 'Optional("AXWindow")', subrole: 'Optional("AXStandardWindow")', identifier: 'nil', modal: 'Optional("false")', windowId: 'Optional("31067")')
hideViaEmulation: Hide Window(title: 'Optional("New Incognito tab - Google Chrome (Incognito)")', role: 'Optional("AXWindow")', subrole: 'Optional("AXStandardWindow")', identifier: 'nil', modal: 'Optional("false")', windowId: 'Optional("31063")')
hideViaEmulation: Hide Window(title: 'Optional("New Incognito tab - Google Chrome (Incognito)")', role: 'Optional("AXWindow")', subrole: 'Optional("AXStandardWindow")', identifier: 'nil', modal: 'Optional("false")', windowId: 'Optional("31067")')
... reapting until I focus on other non-chrome window

Local tested via reverting this commit 588f697 in the latest main branch (e03bfac), the issue looping/bouncing disappears.
But a bit flicker when changing workspaces

If chaging the logic to hide all invisible windows first, then unhide visible windows. No issue but will flicker and show desktop.

--- Update

it seems that the issue is related to the external monitor, and the display arragenement matters.
I put the chrome 1 and chrome 2 in the external monitor, with workspace 1 and workspace 2.

when the external monitor arranges below the build-in display. All the invisible windows correctly hide in the right corner. And when switching between workspace 1 and workspace 2, it will not lead to the looping issue.

Meanwhile, if put the the external display above the built-in display, the issue happens.
And it seems that the invisible windows do not correctly hide in the right corner of the screen. Instead, they appear in the built-in display one by one, and fall into the infinite loop

If I put 2 chrome windows seperately, one in the external monitor and one in the built-in display, I can not reproduce the issue.

[xuyixin1996]

Hi @nikitabobko

I did the bisect to narrow down the issue

Steps:

git checkout <commit_id>
# follow the dev-guide to setup the environment
./build-debug.sh
./run-debug.sh
# try to reproduce the issue, as I mentioned above

As a result

@9ee96e07918bac7a2f9f473f85dc67884dae81b3 no issue
@588f697b09f632576eb565ca3800d805c2eeb0d4 have issue # yes this is the suspioues commit you mentioned above
@7bb24b5f04b1c97fc9154520c5353b674e436c5e  have issue

All points to the commit 588f697 involved the issue and it seems that after this patch, somehow the sequence of hiding and unhiding will lead to this looping.

Sorry but I'm rookie in swift and can not move it forward, if anything I can help with this issue please lemme know.

[nikitabobko]

@xuyixin1996 thanks for the investigation! I will try to reproduce with monitors aligned vertically and take a closer look at the problem later this week. In the worst case, we can just revert the commit.

cc @ilyaluk

Sidenote: it's not the first time I see funky macOS behavior when monitors are arranged vertically

[nikitabobko]

Meanwhile users who are irritated by the bug can temporarily downgrade to 0.11.2

brew uninstall aerospace && brew install --cask nikitabobko/tap/aerospace@0.11.2

[nikitabobko]

I've managed to reproduce the issue. Once again thanks to @xuyixin1996 for the investigation! There are two factors necessary to reproduce the issue:

1. Displays have separate Spaces have to be enabled
2. The most bottom right monitor shouldn't be configured as main monitor. Partially related to Windows will flash-resize with different resolution monitors on workspace switch #149

Outcomes:

1. Since 0.14.0, it's recommended to keep Displays have separate Spaces disabled https://nikitabobko.github.io/AeroSpace/guide#a-note-on-displays-have-separate-spaces
2. The issue should be fixed since 0.14.0. But please make sure that your monitor arrangement is properly configured: https://nikitabobko.github.io/AeroSpace/guide#proper-monitor-arrangement (or you can disable Displays have separate Spaces)

I'd love to hear the confirmation from someone that the issue is fixed in 0.14.0 for them as well

[NicholasFields]

aerospace -v
aerospace CLI client version: 0.12.0-Beta 9cf82feb0c85bea77fedcdc6b8cdba75b5bbf1f8
AeroSpace.app server version: 0.12.0-Beta 9cf82feb0c85bea77fedcdc6b8cdba75b5bbf1f8

System Settings => Desktop & Dock => Displays have separate Spaces Enabled:
Can induce issue

System Settings => Desktop & Dock => Displays have separate Spaces Disabled:
Can NOT induce issue

aerospace -v
aerospace CLI client version: 0.14.0-Beta 96ae7a761f5f969b21e00345629558e005d125c5
AeroSpace.app server version: 0.14.0-Beta 96ae7a761f5f969b21e00345629558e005d125c5

System Settings => Desktop & Dock => Displays have separate Spaces Enabled:
Can NOT induce issue

System Settings => Desktop & Dock => Displays have separate Spaces Disabled:
Can NOT induce issue

---

Thanks @xuyixin1996 for the bisect
Thanks @nikitabobko for the fix