The window switcher advances several icons when alt+tab is pressed

[jsh9]

Describe the bug

The expected behavior of "alt + tab" should be: when I hold "alt" and press "tab" once, there is a box around the second icon (which is the window that will be switched to), and when I press "tab" again, the box moves to the third icon, and so on.

But I've experience the following: when I held "alt" and pressed "tab" once, the box quickly moved from the second icon to the 5th or 6th (or even further) icon within a second.

I triple-checked that I only pressed "tab" once, and I know my keyboard is not at fault here, because I connected this same keyboard to a Windows computer and pressed "alt + tab", and everything was fine.

Steps to reproduce the bug

Please see the description above.

[lwouis]

Hi @jsh9!

I don't reproduce this issue locally. I've seen similar reports in the past that ended up being about external keyboard or software setups (synergy, BTT, etc)

Does it happen every single time? Could you please share more details about your hardware and software setup regarding input?

[jsh9]

It doesn't happen to me every single time. It's sporadic, and I can't predict when it happens.

Here is my hardware setup:

• External keyboard with USB-A
• The keyboard is connected to a USB-C dongle
• The USB-C dongle is plugged into my MBP's USB-C port

I tested this exact same hardware setup on a Windows computer (plugging the USB-C dongle to my Windows machine's USB-C port), and I never see the same issue with Windows' "alt + tab".

I don't have synergy or BTT installed on my MBP.

[lwouis]

Does it happen with the built-in MBP keyboard?

[jsh9]

Let me try it and report back. It may take me a few days because this is a sporadic error.

[jsh9]

I just observed this situation happening with the built-in MBP keyboard.

I was able to observe this situation ~6 times. Each time, the box kept advancing forward after I lifted my finger off the "Tab" key (while still holding down the "Alt" key).

[lwouis]

Could you please use the built-in feedback form and send a report? Just put a link to this url as comment. It will put your preferences in the report and there i may find some clues about preferences that may interact here

[SoPat712]

This has happened to me extremely sporadically, and seems utterly random. I have better touch tool downloaded, and also keyboard maestro, and karabiner elements, so there are tons of things capable of causing this. I have no keyboard shortcuts on btt, and I only use keyboard maestro for fn shortcuts, so it seems like Karabiner is possibly the culprit. @jsh9 do you have karabiner downloaded as well?

[PelegAtVia]

The same problem, using apple magic wireless keyboard, @SoPat712 I don't have karabiner, keyboard maestro, or better touch tool installed at the moment.
I will point out that it seems to me to mostly happen after a while not switching tabs, that is, if I just switched tabs it tends to happen less often. I know how frustratingly unuseful that observation might be, sorry ¯_(ツ)_/¯

[mfn]

I've seen this now too; actually I noticed it the first time today.

Same observations as others: "sporadic" :-/

I've:

• AltTab 6.12.0
• OSX 10.15.7
• using an external Apple keyboard via USB (connected to an adapter connected to Thunderbolt? USB-C? Sorry, I mix up these things)
• 2 external FullHD monitors and the built-in display (= 3 displays)

I don't remember "changing" anythings either hardware or software wise recently.

Also, it's "definitely not the mouse"; the pointer is somewhere else and the selected window advances from the currently selected position. As if I would have pressed TAB once more, but I didn't. I also made sure I didn't press it too long, like, just tapped it quickly, and still saw it.

It seems to go away after selected windows or switching screens

[lwouis]

It could be some data-race since the app is using quite complex concurrent code. That's a nightmare to investigate by the way. Any help welcome 😅

[taikulawo]

It could be some data-race since the app is using quite complex concurrent code. That's a nightmare to investigate by the way. Any help welcome 😅

Same problem, and it happens randomly.

I guess it maybe a key delay.

If I press both command and tab and don't release, window will move to next(I know it's expected).

Could you add a option, window should move to next after we hit tab again

[jsh9]

Could you add a option, window should move to next after we hit tab again

IMHO this would be a very bad design, because it breaks every user's habit and muscle memory.

However, I do think it might make sense to explore setting a time threshold (such as 0.1 sec), after which the app switching actually happens.

[lwouis]

Could you add a option, window should move to next after we hit tab again

If I understand correctly, this option would be toggling on/off key repeat. That is, I press the shortcut and hold the key, and that repeats the action or not. That can already be done today using the (not well known) macOS preferences system.

You can run the following commands in the Terminal:

defaults write com.lwouis.alt-tab-macos KeyRepeat 1000
defaults write com.lwouis.alt-tab-macos InitialKeyRepeat 1000

That would set keyboard repeat to a very high delay, only in AltTab, practically disabling it.

Now that AltTab would expose a toggle for it, I think sounds too niche to be positive value for the global user base. Maybe I'm wrong though, and lots of people would like that?

[jsh9]

Just to follow up on this issue.

Is this solution:

defaults write com.lwouis.alt-tab-macos KeyRepeat 1000
defaults write com.lwouis.alt-tab-macos InitialKeyRepeat 1000

your officially endorsed permanent solution, or just a temporary hack? Thanks.

(Btw, this solution seems to work fine for me.)

[lwouis]

@jsh9 There are 2 distinct topics in this ticket:

• The bug described in the OP. This is a bug where the user invokes AltTab, and the selection cycles to the right too many times, as if the tab key was held. For this, the status is still pretty much that it doesn't happen on my machine, and I need help to reproduce and understand what triggers it
• The discussion about potentially adding a preference to control key repeat rate (maybe change it using a slider, maybe disable it with a checkbox). Here I provided a built-in solution which is to override the system preferences only for the AltTab app using the built-in defaults command. I don't plan on implementing preferences for these. It doesn't strike me as useful, and users are not asking for it actively here. It was discussed as part of a workaround regarding the OP issue, but I can't see users really asking to get control over keyboard repeat rates.

I hope that clarifies where this ticket stands currently 👍

[lwouis]

I got reproduction steps! I was looking at #809, and I noticed the issue from this ticket here happening in a very specific scenario:

• Start LibreOffice
• Invoke AltTab during LibreOffice start
• AltTab will take a while to appear (may be the root cause of AltTab's window sometimes "hangs" for 0.5 to 1.5 sec after choosing a window or cancelling #563!), and after it does, acts as if the tab key was held, even though it's not

The timing window is small, but if AltTab is invoked right at a certain time during LibreOffice startup, this issue is reproduced consistently!

I think this is great ground to finally debug and understand what's happening here, and possibly in #563 👍

[taikulawo]

@lwouis Good news, I hope that will help you to fix this serious bug, which broken experience

[lwouis]

Damn, I tried to steps above today, and after 20 tries I can't reproduce the issue I witnessed yesterday.

It seems to indicate that it's not really the interaction is not about the app, but about the OS itself. I can imagine for example WindowServer being saturated/busy, and blocking some calls. That would happen only in cases where the OS is under particular load (maybe lots of GPU heavy things like multiple videos running, maybe lots of CPU tasks, maybe networking, etc).

That being said, I already put all the blocking (to my knowledge) calls in queues on other threads, so they shouldn't block the UI thread for instance.

It's also possible that something else is happening here that I can't imagine.

[taikulawo]

Damn, I tried to steps above today, and after 20 tries I can't reproduce the issue I witnessed yesterday.

It seems to indicate that it's not really the interaction is not about the app, but about the OS itself. I can imagine for example WindowServer being saturated/busy, and blocking some calls. That would happen only in cases where the OS is under particular load (maybe lots of GPU heavy things like multiple videos running, maybe lots of CPU tasks, maybe networking, etc).

That being said, I already put all the blocking (to my knowledge) calls in queues on other threads, so they shouldn't block the UI thread for instance.

It's also possible that something else is happening here that I can't imagine.

Have you try to run heavy CPU jobs when switching? It's sure happened to me when I run many background processes in development

[lwouis]

I think I may have found the root cause of this:

Sometime, while AltTab UI is open, an app in the background will do something that steals the key focus away from the AltTab window. When this happens, AltTab misses when the user releases the tab key, thus the key repeat timer repeats endlessly.

Example of events that steal focus from AltTab: an app in the background becomes active, an app in the background has a window which becomes key, or creates a new window. There are other cases which I still don't know why the focus is stolen.

I think a workaround would be to detect when AltTab window loses focus, and quickly restore it if it should be having it.

[yangmillstheory]

Hi,

I'm experiencing this problem on Ventura 13.6.4; can we reopen this issue? I think the problem correlates to the keyboard settings

• Key repeat rate
• Delay until repeat

The speed at which Alt+Tab will cycle through apps when it's pressed correlates directly to the setting above (faster repeat rate implies faster cycling).

FWIW, I have an Ergodox EZ connected to my MBP by USB-C. Happy to help in any way and thanks for this wonderful software.

[lwouis]

@yangmillstheory this issue here is closed. Are you perhaps experiencing this issue? #3117

Side-note: AltTab purposefully reads the OS for the 2 variables you mentioned. It's done on purpose so if you keep tab pressed, it repeats, and it repeats at the rate that you set your repeat to, globally for the OS.

[yangmillstheory]

It's done on purpose so if you keep tab pressed, it repeats, and it repeats at the rate that you set your repeat to, globally for the OS.

I don't actually press Alt+Tab. I have a key binding that sends the Alt+Tab activation keys (in my case, Command+Tab):

My AltTab (v6.64.0) preferences in case it helps:

I'm not sure if this is the same issue as #3117. The problem happens sporadically, and seems to be independent of where my mouse is positioned. Anything else I can do to help debug the issue?

[lwouis]

@yangmillstheory Does the issue happen when pressing alt+tab normally? Many people have reported issues which were due to setups like yours, with software remappers. It may be the issue here, not AltTab

[yangmillstheory]

It could be an issue with my keyboard; based on some non-rigorous spot testing, it doesn't seem to happen on my laptop keyboard. Are there any common courses of action for folks using software remappers? I'd guess not, and it depends on a case-by-case basis.

[lwouis]

You may want to compare the events sent by your remap vs native inputs, using this tool. It may showcase what the remapper is doing wrong

[yangmillstheory]

With that, I'm seeing

Screen.Recording.2024-01-28.at.21.59.36.mov

consistently, particularly when the problem happens. But this only seems to happen when I press the key that maps to the Alt+Tab keybinding, not the keybinding sequence itself (modifier key + Tab).

I suspect that this isn't a problem with AltTab, so I'll continue to try and debug this myself. Thanks for your help!