Looping/Bouncing Between Workspaces about aerospace

[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.

[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

[adamdottv]

Also, here's a vid repro.

Yep, that's exactly what I see!

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

[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?

[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

[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.

[LeandroLovisolo]

Also, here's a vid repro.

Yep, that's exactly what I see!

[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

[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