Looping/Bouncing Between Workspaces

[NicholasFields]

Context:

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

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

https://github.com/nikitabobko/AeroSpace/assets/68744844/89cff7fc-c4db-4735-bda0-fec3d01b7899

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