Switcher sometimes starts on the first window instead of the second

[jason5122]

Describe the bug

Sometimes, the app switcher will start on the first window instead of the second.

Screenshots / video

alttab.bug.mp4

Steps to reproduce the bug

I'm not too sure how to reproduce — I believe it's related to window pop-ups since the bug above was recorded right after a Wi-Fi pop-up appeared. I've tried a few times unsuccessfully to reproduce.

System Info
macOS 11.1
AltTab 6.26.0

[lwouis]

It may be related to the other ticket about popups breaking on macOS 11: #718

Also note that there is 1 use-case where it's correct to have the first window in the list selected by default: when you focus an app without any window. A easy way to do this is to click on the Desktop for example. There are no active window then, so the "previous active window" is now the first in the list, not the second (because you would be already focused on the first). That being said, this use-case doesn't seem to be involved on your video.

[khour]

I don't think it's related to popups. Can happen without them w/ default apps, see attached screencast.
It won't switch the window until I hit alt tab twice (first to bring the switcher, second to actually switch the window). After that, first alt tab invoke starts to properly switch windows.
It's interesting that it doesn't happen with every app. Like in my example, if I replace activity monitor with sublime text, alt tab works properly from the get go and doesn't skip the first switch.

bug_h264.mov

[lwouis]

I was able to reproduce the issue by simply launching AltTab. I'm on Catalina. On a fresh start, with existing windows, I notice that the selected thumbnail is the leftmost, when AltTab UI shows. It should be the second to the left, not the first.

It's probably a bug in the code that handle the edge-case where there is no focused window (when you click the desktop for example).

I'll look into it

[lwouis]

Ah, yes indeed it's exactly what I mentioned above.

When AltTab is opened, it asks the OS for the active app, and checks if it has an open window. If it does, then we select the second thumbnail. If it doesn't, we select the first thumbnail.

As I said, this is useful for cases like clicking the finder. In that case, you want that behavior.

The bug comes from the fact that when AltTab is brought up and asks the OS for which app is the active app, the OS will sometimes return... AltTab itself.

I need to find a new approach to detect the active app before AltTab is brought up

[khour]

Some updates on what I found out while using AltTab.

It's indeed a specific set of applications, which when launched, make AltTab stuck on its first entry.
Apps affected that I found: disk utility, activity monitor, system preferences, mail.
Order matters, as the issue is only present when the problematic app is launched last. For instance: launch mail, then calendar -> AltTab properly switches to the second window (i.e. to mail) from the start. But launch calendar, then mail -> AltTab is stuck on the first window (mail), and requires hitting tab again to get to calendar. After that it works properly.
All of that makes me think that there's something fishy about certain apps and their windows. As far as I see, it's only standard apps that are affected, but maybe I've just yet to encounter a 3rd party with the same behavior.

Sorry for the info dump. I'm getting familiar with the AltTab code for now, and kinda using this ticket as a logbook in case you won't have time to handle it so that I can eventually get to it and fix it, as it's bugging me a lot.

[Willem-SN]

This happens all the time for me. Most apps will focus on itself the first time pressing alt-tab. But when going out of the window, and getting back into it, it will work properly. I've tried a lot of different settings configurations just it case, but the issue always persists.

Apps that has the bug: calculator, forklift, transmit, safari, vlc, iterm, system preferences (so most applications)
Apps that always work properly the first time: sourcetree, vscode, discord (first splash window works as well) -> can't find any others

log from the bug, opening calculator and then pressing alt-tab (focuses calculator)

"OS event" "apps launched" [(74706, Optional("com.apple.calculator"))]
"Adding app" 74706 "com.apple.calculator"
"Adding window" 59563 "Calculator" "com.apple.calculator"
"showUiOrCycleSelection"
"showUiOrCycleSelection: isFirstSummon"
"Accessibility event" "AXFocusedUIElementChanged" "nil"
"Accessibility event" "AXFocusedWindowChanged" ""
"Accessibility event" "AXWindowCreated" ""
"Deinit window" "Calculator" "com.apple.calculator"
"Deinit app" "com.apple.calculator"
"focusTarget"
"hideUi"

[altfoxie]

Apps that has the bug: calculator, forklift, transmit, safari, vlc, iterm, system preferences (so most applications)

Same happens to me

[altfoxie]

@lwouis any updates on this? This bug is very annoying

[lwouis]

@altfoxie it seems i found the root cause: #1198 (comment)

so it's about working on it now. Anyone is welcome to share a PR. Me, i have very little time for this project, unfortunately (see pinned issue).

[lwouis]

I was wrong in my assessment above. When I launch AltTab on my machine, it keeps focus on the app that had focus previously, but it removes focus on the window that had it.

This is why AltTab selects the first thumbnail instead of the second there.

Now, I managed to reproduce the issue from the video from @khour above. I also managed to debug and understand. Here is the root cause:

Some apps, like Activity Monitor, don't trigger a AXApplicationActivated or kAXFocusedWindowChangedNotification or kAXMainWindowChangedNotification after they are launched, even though they are active/activated. I don't know why this is. Maybe it's linked to this Keep CPU windows on top?

There seems to be lots of crazy things going on with Activity Monitor. Look at this doc from Apple for instance:

In any case, this trips AltTab because during these events, we check if there is a focused window for an app.

As a workaround, I added code to check for the focused window during window creation, which should ensure we don't miss the info, and the issue from this ticket is fixed.

I'll release a fix soon