Long delay until Alt-Tab opens

[vladunev-tomtom]

Since version 7.x the time between pressing the hotkey (sey Cmd+tab) and Alt-Tab actually showing can take long time - 5, 10 seconds and more. Usually after the 5th second I start repeating the hotkey and Alt-Tab appears. This seems related to issue #3839.

Steps to reproduce the bug

1. Just run some more demanding programs. For example, Unity 3D, SideFx Houdini or Photoshop, especially if two or more are running at the same time.
2. They do not noeed to be doing anything, can be minimised/hidden, and still the problem is there.
3. I would expect the problem is caused by Alt-Tab trying to capture windows from the running apps. But the problem is still there even if I disable window previews.
4. The problem is very pronounced in latest versions. I've downgraded to 6.73.0 and so far havent noticed it happening (but I love the updates in 7.x so looking forward to use them again)

Your environment

• AltTab version: 7.xx has the problem - 6.xx seems ok.
• macOS version: Sequoia 15.1
• Other relevant info:

• happens on battery AND while plugged
• using external bluetooth mouse (MS Precision Mouse).

[lwouis]

Hi,

Could you please share a video of this issue?

Does it happen on v7.3.0?

You mentioned that the issue seems related to issue #3839. What makes you think that? The symptoms you described seem different than this other ticket. Do you experience the selection going to the last item without you holding tab?

Thank you 🙇

[vladunev-tomtom]

Hard to share a video of something that is not happening. But the description is: I press Cmd+Tab (my hotkey), nothing happens immediatley (I wait) sometimes alt-tab opens. Or I start pressing Cmd+Tab till finally it opens.

7.3.0 was the version I finally gave up and reverted back to 6.73. But it was happening for a couple of weeks now, 7.3.0 just made it unusable to me. Problem is, it coinsided with multiple changes - Sequoia, Unity new versions... that's why I didn't pay much attention initially. But with the same OS, with the same programs and back to 6.9 I don't notice the problem anymore.

Why I think it might be related to #3839? If this was Windows, I would say "it feels like other programs are taking priority over the processor (or keyboard interrupts?) and Alt-Tab gets stuck waiting for GPU or CPU time". But I have no clue how internally Mac (or Windows, for that mater) works. Just a hunch.
I subconciosuly label all this as "lag". Lag to open Alt-Tab. Lag to accept keyboard input (so the focus loops over apps like in #3839). Lag to accept keyboad input to select window and close Alt-Tab. But I agree the underlying reasons can be completely different.

Sorry for the long-winded (and dyslexic) answer, trying to provide more info :).

[vladunev-tomtom]

Added screen recording.

[vladunev-tomtom]

Some more info: switched to 7.2, and dont notice the effects I was commenting about in 7.3.
Same setup, havent restarted the machine, same programs. In all of the above cases I'm running without window previews, only app icons.

[Bacto]

Hi,
I have the same problem (Macbook Pro M1 Max).
I rebooted but same problem.
Just tried again now and it works for few minutes and then it begins to be super slow and unusable :(

[vladunev-tomtom]

@Bacto , I wonder if yor care to rolback to 7.2, would it work better? In my experience it is Ok, but I use it without window previews.

[Bacto]

7.2 seems to work great.

[lwouis]

Thank you @vladunev-tomtom for the great info 🙇

@vladunev-tomtom @Bacto Could you please run these commands in Terminal.app and share the results?

defaults read -g KeyRepeat
defaults read -g InitialKeyRepeat

Thank you

[oscargong]

Thank you @vladunev-tomtom for the great info 🙇

@vladunev-tomtom @Bacto Could you please run these commands in Terminal.app and share the results?

defaults read -g KeyRepeat
defaults read -g InitialKeyRepeat

Thank you

I got same issue, here is my results

2024-11-17 01:26:19.263 defaults[8626:12488507] 
The domain/default pair of (kCFPreferencesAnyApplication, KeyRepeat) does not exist
2024-11-17 01:26:19.273 defaults[8627:12488510] 
The domain/default pair of (kCFPreferencesAnyApplication, InitialKeyRepeat) does not exist

[Bacto]

Thanks @lwouis for you follow-up.

Here is the result:

defaults read -g KeyRepeat
2

defaults read -g InitialKeyRepeat
15

[vladunev-tomtom]

defaults read -g KeyRepeat
2
defaults read -g InitialKeyRepeat
15

[stevehoek]

I'm experiencing the same issue with 7.3.0 and it goes away when reverting to 7.2.0

My key repeat values are 2 and 15 like others have shown.

[lwouis]

Hi,

Could you please test this local build, and let me know if the issue happens with it?

Thank you 🙇

[vladunev-tomtom]

Testing, thanks!

First impressions are that in Icon-only mode it works perfectly (fingers crossed).
With window previews I can feel slight delay at times, but it feels much more predictable than 7.2 and especially 7.3.

What is important, the delay happened while I was rendering in After Effects, which is a pretty heavy load. I've attached a screenshot of all the stuff I have running normally. This would be expected on windows, I feel on Mac this count as extremism :)

P.S. For madman users like me, would it be possible to have the names of all windows under their icons? It's how 6.9 works, more or less. This would allow distinction between different window icons of the same program. Of course, most people are here for the window previews, so maybe I'm an outlier with this request.

[lwouis]

I'm able to reproduce this somewhat, suing stress -m 16 -c 16 -i 16 -d 16 on my machine.

I press and release the shortcut quickly, then there is a delay to show AltTab UI, then sometimes the UI stays open even though I released the keys.

I'll dig deeper into this issue now that I can somewhat reproduce the issue 👍

[stevehoek]

I've been using the special build for about an hour and havent seen it. I have alot of browsers and tabs open so there is memory pressure but CPU usage is not too stressed, fwiw.

[lwouis]

Hi everyone,

Could you please try out this build? I think I've nailed down the data-race, and that this build will never leave the switcher UI open if the keys are released.

At least, I can't reproduce any issue with this build.

If it helps you, you can run the same command I use to generate load artificially in my machine: stress -m 16 -c 16 -i 16 -d 16. You can install stress with brew install stress.

Thank you 🙇

[stevehoek]

I'll give it a try... the previous special build has shown the problem at least once since I've been using it for a few hours.

[lwouis]

Thank you @stevehoek

the previous special build has shown the problem at least once

The previous build was me reverting one commit from v7.3 to how the code was in v7.2. I wanted to narrow down if that commit was the root cause of your issues.

Your results seems to confirm that the problem was also happening in v7.2, and was perhaps worsened in v7.3, but not introduced there.

Ideally, if the build I shared works for everyone, we can move forward to the next release with it, and forget about this issue 👍

[stevehoek]

@lwouis
Been using it heavy all day and havent seen the issue!

[stevehoek]

@lwouis does the new 7.4.0 include this fix?

[vladunev-tomtom]

Sorry to say that both new builds, while feeling somewhat better, does not solve the issue for me. For comparison, 6.9 still continues to work for me even with heavy load, even with window previews. Window previews are big nono for the 7.x versions - not that it can't display them, but it hickups much more often with window previews.

In icon-only mode, I notice with both new builds that when it does not respond to hotkey, I wait, then start alt-tabbing multiple times, and in goes through a strange process of drawing the icons - they first appear blurry and slightly larger, then snap to the right size and get crisp.
Also it tends to redraw/blink the Quickitme and Teams icons.

[lwouis]

Hi,

There are multiple different issues in this thread, I think. Here's what I gather from everyone has shared so far:

1. AltTab stays open after I have released the shortcut fully
2. AltTab takes a while to appear after I press the shortcut
3. AltTab doesn't appear after I press the shortcut. I have to press it again
4. AltTab doesn't appear cleanly. It appears progressively, in a glitchy sequence

So far, I've identified 1 issue on the tech side: under heavy load, macOS can send key events in the wrong order. It can also not send some key events. I'm planning to add support for this. It will not work for every case, but should handle most cases. This should fix issue number 1 listed above.

I'm not sure what root causes lie behind issues 2, 3, and 4.

Thank you

[stevehoek]

@lwouis the most recent special build is working well for me for 2 days now... does 7.4.0 include its fixes? or should I not update

[lwouis]

@stevehoek no. These changes are not in any released build

[stevehoek]

@lwouis the change in the most recent special build from this thread is still working well for me. It would be nice to have the change in a public build.

[timothyvermeiren]

I hope it's okay to still comment on this issue given that it's been closed, but feel free to redirect me if needed.

I have been using 7.8 for two days now and I'm afraid that I am still experiencing the issue. It can take up to 20 seconds for AltTab to react when the keyboard shortcut is used; though it happens only a few times a day, after the shortcut has not been used for a longer time.

Feel free to let me know if there is any information I can provide to help figure out where the cause may lie (as it might thus not be with the thumbnails...)

[be9em0t]

To support what @timothyvermeiren wrote:

First, the good news are that the update solved most of the problem. Alt-Tab reacts immediatly now. No more unpredictable delays before it opens, and it seems to work well under load. I think this is the async windows display working as it should. Thank you @lwouis!

That said, in 10 hours I've experienced twice a situation as described by @timothyvermeiren.
Very long delay, or maybe it will not open at all - I had about 20 sec of patience clicking Command+Tab, than released the keyboard and tried again. On the second try it opened as it should.

Both times the situation arose at the first Alt-Tab use after the machine was left untouched for a relatively long time - 20-30 minutes.

So, the problem might be related to not accepting keyboard keys after idle. Or might be related to some behavior of Alt-Tab where it waits for stored images of the windows, which are no longer available in memory? At any rate, this feels like a new problem.

Question to @timothyvermeiren: do you have some potentially conflicting programs like Karabiner or BetterTouchTool running? I have both, and while Karabiner has never caused me a problem in 6 years of usage, I don't have extensive experience with BTT.

Alt-Tab v.7.10
Macbok Pro, Apple M1 Max, 64Gb

[lwouis]

Please @timothyvermeiren @be9em0t, disable all remapping software, use internal laptop keyboard, etc, in your tests. This way we can isolate if the issue is actually with AltTab, of if it's with something else that gets in the way. Thank you 🙇

[timothyvermeiren]

Yes, @be9em0t, what you say all aligns with my experience! I do have BTT, so I'll disable that now as suggested.

@lwouis, to ensure testing goes well:

• ✅ I am always using the internal keyboard.
• I have now disabled BetterTouchTool as well as Espanso, which are the only two apps with remapping I use.

I'll report back on the situation later...

[be9em0t]

Ok, here is the result of one more day of testing 7.10:

• turned off BTT to ensure clean environment (cant turn off Karabiner, beause then mac becomes unusable to me)
• everything went well for at least 5 hours
• then launched Adobe After Effects and immediately things changed:
  With Adobe AE, the AltTab swiching between windows remained stable and fast, BUT
  on many occasions AltTab would not show on initial hotkey press, and on a couple of occasions wouldn't open even after repeated tries. None of this was related to the laptop being idle, it all happened in the course of normal work.

My feeling still is that the problem with waiting for window previews to display is solved by the async fix, and this bug here is caused by something else.

One thing to try is using Option+Tab to invoke it instead of Command-Tab, as I usually do. Maybe it's just some bug in Sonoma that randomly blocks Command-Tab, being internal macos hotkey?

One final note, in my experience Adobe programs are very agressive both on Mac and on Windows , breaking other programs in subtle ways. That said, I haven't noticed this kind of problem on AltTab 6.xx.

[lwouis]

@be9em0t thank you. Maybe Karabiner is interfering

[stevehoek]

@lwouis I agree with @be9em0t that the preview update is solved but this issue is a different bug that causes the preview window to not show in a timely fashion after pressing alt-tab. As a user if you don't get the result you expect you press the key combo again. Worst case I've had to wait 30-45sec before it shows. It is usually when my machine is under stress (M3 Max but 100's of tabs open, spreadsheets, remote desktop, etc)
I do also run Karabiner but can't disable it as it is really helpful with my Windows RDP sessions.

[stevehoek]

@lwouis so I just had it happen that I had to hit alt-tab 5 times before the preview came up. The machine is not loaded right now, but there are two full screen remote desktop sessions open (but not the currently focused "window/space").
The worst I've seen is maybe 20 presses before it showed (maybe 30 sec elapsed)

[lwouis]

Thank you @stevehoek. An issue we face is that if everyone who faces the new issue has Karabiner running, then we can't be sure that it's not a Karabiner issue. It's reasonable to expect that it is indeed a Karabiner issue if few people face it, and all of them run the app.

I'm not sure what I can do to debug this issue further. Indeed, I've never reproduced it on my machine.

[stevehoek]

@lwouis that is understandable, but i have been running the same verrsion of Karabiner for quite awhile and didnt have this problem until recently, the 7.x timeframe for AltTab I'd guess.

[Koolstr]

@lwouis On the latest version, I'm still experiencing the long 10s delay until it finally shows up, and I don't have or use Karabiner. So this isn't tied to Karabiner interference, per se.
For what it's worth, I'm running Alt-Tab on macOS 10.15.7.

[imkebe]

Yes. It came back to me too.

[vladunev-tomtom]

@imkebe - do you happen to have Karabiner too?

I looked up at Karabiner site and they appear to have some problem with Karabiner behavior after wake up from sleep. So I've took to restarting Karabiner after heavy load or after wake. Everything behaves perfectly now, as opposed to earlier when AltTab plainly refused to open on multiple occasions.

It would be nice if the solution is so simple, though this does not explain why this became a problem only in 7.xx

[lwouis]

@Koolstr do you have any software interfering with keyboard input (e.g. BTT)? Do you use an external keyboard? Non-English keyboard layout? Etc

[imkebe]

Yes. I have Karabiner installed. Nothing fancy. ISO Keyboard. Some complex modifications for Dev related tools to use Fn keys. Etc.
No BTT.

About the keyboard... Whole day i'm using external BT Logitech Keyboard. Now on MacBook internal one - no issues so far.

[vladunev-tomtom]

Thanks, @imkebe. This starts to look like a pattern.
I'm sure we'll find a way to run AlTab and Karabiner together, but first we've got to actually diagnose the problem.

[imkebe]

Karabiner-Elements 15.3.0

Karabiner is installing an system extension - org.pqrs.Karabiner-DriverKit-VirtualHIDDevice

External keyboard setup.

I've opend the Karabiner-EventViewer and it shows a Unknown Events when I've activated the Alt+Tab on my external keyboard.

[
  {
    "value": "1",
    "usagePage": "8 (0x0008)",
    "usage": "2 (0x0002)"
  },
  {
    "value": "0",
    "usagePage": "8 (0x0008)",
    "usage": "2 (0x0002)"
  }
]

Maybe this help a little. Also I've maped the native Alt+Tab to be used for AltTAb.
When I'm using a external keyboard it's connected via BT but also the majority of the devices are connected via TB4 Hub including 3 screens....

[lwouis]

Ok so everyone is using Karabiner. It's clearly an issue on their side, or in your particular setups then.

I'm sorry but i can't help with external tools. I'll close the ticket. Please discuss this on the Karabiner repo.

Thank you 🙇

[timothyvermeiren]

I do not have Karabiner (sorry 😬) but I do have BetterTouchTool and Expanso.

Same symptoms as described the others (very long delay before any reaction). I'll try another day with these two disabled and see if there's any difference.

[vladunev-tomtom]

@timothyvermeiren With Karabiner I find that restarting it automaticaly on wake makes the problem go away (they even have shell script to do this for you).
Maybe the same approach would help with Expanso?
I also have BTT and it does not seem to matter if it's running or not.

[timothyvermeiren]

I can try that, thanks @vladunev-tomtom.

One more thought here @lwouis: I am not sure the keyboard shortcut is effectively intercepted by another program. I found that it's effectively AltTab become unresponsive, because when I try to e.g. access its preferences with the icon in the menu bar, it shows the spinning beach ball icon. This lasts for as long as the delay we experience, and as soon as that's over, AltTab shows up and the icon becomes available again.

Is there something else I can do to troubleshoot this particular situations? Would logs of any sort be relevant here?

[lwouis]

Thank you @timothyvermeiren
Could you run AltTab with logs? You can run from Terminal.app with /Applications/AltTab.app/Contents/MacOS/AltTab --logs=debug. It would be very interesting to see what's being logs while the spinning ball is shown.
Thank you

[vladunev-tomtom]

I found that it's effectively AltTab become unresponsive, because when I try to e.g. access its preferences with the icon in the menu bar, it shows the spinning beach ball icon.

I had the same experience, icon not responding!

[timothyvermeiren]

Thank you @timothyvermeiren Could you run AltTab with logs? You can run from Terminal.app with /Applications/AltTab.app/Contents/MacOS/AltTab --logs=debug. It would be very interesting to see what's being logs while the spinning ball is shown. Thank you

Ah, excellent! Alright, I'll run the app with debug logging for a while.

[lwouis]

Hey everyone,
Let's move our conversation about AltTab freezing and taking CPU to this thread: #3986
This way, we can have clearer com since it seems to be a different issue than the OP here.
Thank you