After opening AltTab, it seems like the Next Window shortcut is held or pressed a few times without the user doing anything

[SamadiPour]

Describe the bug

Since a few weeks ago, I have been experiencing drifting when the mouse is hovered over an item. It only happens when the mouse is over an item, and not when it's inside or outside of the frame.
When I hold down the Command key and press Tab once (push and release instantly), the selector drifts through the items, sometimes until it reaches the mouse and sometimes until it reaches the end.
The Mouse hover option under Also select windows using is disabled.

Screenshots / video

Screenshot.2024-01-19-jK5O4SMZ1.mp4

Steps to reproduce the bug

Your environment

• AltTab version: 6.64.0
• macOS version: 14.2.1

[warrenseine]

I experience the same issue with the same environment. I reverted to 6.63.0 and the weird behavior is gone.

I suspect this is related to this commit.

[lwouis]

Thank you @warrenseine for sharing this message.

@SamadiPour does v6.63.0 also fix the issue for you?

I don't see how the issue would be related to the commit though.

@SamadiPour on your video, I see some flickering on the right part of AltTab's window. I'm wondering if you are not suffering from #1840. Could you please show the top menubar of your screen, when the issue happens? If there are 2 AltTab icons, that's the source of the issue right there.

[SamadiPour]

@lwouis Just tried v6.63.0, and it seems like I can't see the issue anymore. I will test more to make sure.

Also, flickering might be because of video compression or the recorder. I didn't see any flicker while using it. I also checked the processes and top menubar, and there was only one instance running.

[SamadiPour]

Update: I have not experienced the issue since downgrading to v6.63.0.

[ankushagarwal]

I can confirm that this happens to me as well. I am on the app version 6.64.0. I am on the latest macOS Sonoma version 14.2.1

https://www.loom.com/share/76a2006f084b4b52880ec7a25879958e

[ythosa]

the same problem

[esserrge]

I had this problem on Sonoma 14.2, it does not seem to happen after upgrade to 14.3. Running alttab 6.64.0 on both versions.

[agmitron]

The same here

[Warkanlock]

Same here; it's getting annoying, but I don't want to just throw the issue to maintainers. I'll be happy to contribute if any core maintainer could give me the issue!

[lwouis]

@ankushagarwal from your video, I wonder if this issue is related in any way to the mouse. Can you reproduce the issue without moving the mouse at all, with the mouse outside the AltTab UI?

Same question for @SamadiPour: can you reproduce the issue without having the mouse hover AltTab?

It looks to me like it could be about key repeats, and maybe external keyboards or software keyboard remappers.

[warrenseine]

I do use BetterTouchTool, but only to bind shortcuts.

I use the trackpad and generally don't touch it while alt-tabbing. But it's possible that the cursor is on top of one of the window tile when I alt-tab. I'll monitor.

Also, I'd like to re-iterate that it's very much likely a regression in 6.64. I reverted to 6.63 and didn't have the issue for a week, then I accidently auto-updated back to 0.64 and the bug started again. I re-installed 6.63 once more.

[lwouis]

I'm suspecting that it is not a regression introduced in v6.64. I suspect it because the only code change that could potentially impact is 3b0194d, and I can't imagine how it would interact with the use-case here. I may be missing it, but I could also be guessing right, in which case the issue is not about AltTab, but about something with your environments.

Many people have thought AltTab was bugged, and later realized that the root cause was their external keyboard, software remapper, rare keyboard layout, key repeat settings, etc.

In the case that the issue would be a regression from AltTab, it would be important to establish if indeed the mouse position or movement is involved, or if it's purely a keyboard event issue. The code change only deals with keyboard events, which is why I'm suspecting that the mouse may not have anything to do with the behaviors we see on the various videos.

[np25071984]

I experience the same.

Noticed strange thing about the app switcher window - when there are two apps (Slack and Mictosoft Teams in my case) and the mouse cursor is somewhere around the switcher area, after I pressed app switch combination the switcher window remains on the screen. Having hard time reproducing it yet but it is definitely the thing. Have caught it many times so far. I believe it is relevant to the topic.

[micpiatek]

Can confirm that I was experiencing the same issue on 6.65.0 and reverting back to 6.63.0 fixed it. Whenever I would move my mouse when using AltTab, the selection window would spaz out and be completely unusable until after restarting the app.

Similar issue that was closed here #3168

[harshmandan]

Same problem here.

I couldn't switch windows using alt+tab whenever the mouse was over the switcher UI, even if I did not move the pointer, the switching would glitch out and wouldn't work.

To make it work I have to move the cursor away from the center (to be specific, outside the switcher overlay) and then alt-tab would work fine.

Reverted to v6.63.0, it's working fine now.

[RecuencoJones]

I've been trying 6.63.0 for a couple days and thought it was fixed but apparently it technically isn't, I still get the option drifting but way less often than with latest version.

[warrenseine]

Yes, same here. I've reported that it was ok in 6.63.0, but after a few days / weeks, I've noticed the behaviour too.

[lwouis]

It looks like my hypothesis was right then.

The issue is either with some external factor like third-party hardware or software, or it's an AltTab issue with has been here for a while, before v6.63.0.

[harshmandan]

I degraded to 6.63.0 after running into this problem and I posted about it here.

I also wanted to share the video of what I was seeing. So I recorded my screen with the degraded version 6.63.0 working normally, then I installed 6.65.0 but I could not reproduce the behavior I was facing before. It's super weird. It has been only a day and If it returns I'll record and add a video here.

Regarding external factors, I use BetterTouchTool (to map gesture on trackpad to open a link in a new tab) and I do use an external bluetooth keyboard.

So maybe it could be related to something external, 🤷‍♂️.

[lwouis]

Can anyone reproduce the issue without having the mouse hover the UI? I would like to understand if the issue is related to the mouse hovering the UI, or not.

[broegaard]

I have also experienced something similar to this problem randomly through months (maybe years), but not with 6.65.0.

I have a gut feeling that it might have something to do with cpu load, but I cannot reproduce it.

[nyanpasu64]

The bug is very intermittent for me but I got a related (not quite identical) occurrence on my self-built binary with logging:

@discardableResult
fileprivate func handleEvent(_ id: EventHotKeyID?, _ shortcutState: ShortcutState?, _ keyCode: UInt32?, _ modifiers: UInt32?, _ isARepeat: Bool) -> Bool {
    debugPrint("handleEvent", id ?? "nil", shortcutState ?? "nil", keyCode ?? "nil", modifiers ?? "nil", isARepeat);

This printed:

"handleEvent" "nil" "nil" "nil" 256 false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.down "nil" "nil" false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.up "nil" "nil" false

This implies that the app saw the Cmd keypress released before the Tab keypress was registered, yet it still brought up the AltTab UI. It never closed because the Cmd keypress never got released after the UI opened. (In this case I didn't get an endless Tab key repeat alongside the stuck-open Cmd keypress. I want to take a log of that too when it happens.)

For context, handleEvent is called from three sites (according to Xcode):

• CGEvent.tapCreate(... callback=cgEventFlagsChangedHandler) (modifiers pressed/released)
• addGlobalHandlerIfNeeded { InstallEventHandler(callback=closure) (keys pressed/released)
  • with event filter EventTypeSpec(eventClass: OSType(kEventClassKeyboard), eventKind: OSType(kEventHotKeyPressed)) or OSType(kEventHotKeyReleased)
• addLocalMonitorForKeyDownAndKeyUp() { NSEvent.addLocalMonitorForEvents(callback=closure) (irrelevant, only used by settings panel)

To me this is a clear race condition in event handling. (Unfortunately, like many race conditions I'm unable to reproduce it easily.)

• My initial guess was that modifiers and keypresses are handled in different threads or async sequences, which can be interleaved so the cgEventFlagsChangedHandler(cmd released) fails to update a flag which controls whether InstallEventHandler(closure) should open the AltTab menu or not.
• But apparently the closure unconditionally calls handleEvent, yet handleEvent is not called on every keystroke. At this point my guess is a race condition or logic error where if the app lags or the input queue fills up, InstallEventHandler sends a Cmd+Tab hotkey event to the app, but this (asynchronously?) enters the app's input queue after the Cmd key release gets delivered and processed by the app.
  • Maybe the Cmd press, Tab press, and Cmd release enter the app's input queue, then the Cmd+Tab hotkey gets recognized and appended to the end of the queue instead of replacing the Tab press? IDK.

How should we address the bug?

• We could dig into the macOS/Cocoa/Carbon event delivery system and see how it generates modifier and EventHotKey... events and inserts them into the input queue.
• We could look up the macOS-specified ordering guarantees of modifier and hotkey events, to see if macOS is violating its contract or we're relying on incidental unreliable properties.
• We could ignore event keypresses if we receive a hotkey event but not all modifiers necessary for that hotkey are currently pressed, according to the most recent cgEventFlagsChangedHandler call.

(Sidenote: apparently InstallEventHandler belongs to CarbonEventsCore? I didn't know modern macOS still had Carbon libraries present and supported... Should we port the program off it or not?)

---

I still don't know the cause of the other bug behavior where positioning the mouse where the AltTab popup would spawn, would make it not close. I have not replicated that issue with logging yet.

[nyanpasu64]

Got a different issue where the Alt+Tab menu didn't close for like 2 seconds after releasing Cmd.

"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" "nil" "nil" "nil" 256 false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" "nil" "nil" "nil" 256 false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" "nil" "nil" "nil" 512 false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" "nil" "nil" "nil" 256 false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" "nil" "nil" "nil" 256 false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.down "nil" "nil" false
"handleEvent" "nil" "nil" 33 256 false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.up "nil" "nil" false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" "nil" "nil" "nil" 256 false

• I didn't look into how various event handling inputs correspond to the menu opening or closing.
• After the popup was remaining open, I pressed and released Cmd, but the logs never showed my second release.
• It seems that NSEvent.addLocalMonitorForEvents is not actually only used in the settings menu, but to handle keystrokes while the popup is open.
• According to https://stackoverflow.com/questions/3202629/where-can-i-find-a-list-of-mac-virtual-key-codes, keycode 33 is the [ key. I confirmed this produced code 33 in the logs, but when I tried pressing the key during an Alt-Tab operation, I heard a warning beep and the menu did not remain open. I don't know why my observed behavior happened.

[fderop]

I have found a way to make this bug go away, and it probably explains why "trying $random version" also helps a lot of people — changing versions should always fix it:

going to System Settings -> Privacy & Accessibility, removing AltTab, and then re-adding it back fixes the skipping for me.

This also worked for me.

System settings -> Privacy & Accessibility -> Accessibility -> Switch AltTab off and back on.

[jordantrizz]

This also worked for me.

System settings -> Privacy & Accessibility -> Accessibility -> Switch AltTab off and back on.

Same, perhaps the original issue should be updated with the workarounds. Would save folks some time.

[nyanpasu64]

I've found a semi-reliable way to reproduce a version of this issue:

• Start Alt-Tab and let it run for some time. (I don't know why, it may be related to GC slowing down over time, floating-point timestamp imprecision in the Carbon event translation layer, sleep-wake cycles, running macOS applications that slow down input handling, or something else.)
• Alt-tab twice rapidly, with the mouse over the window. Apparently a combination of long runtime and mouse events entering the Alt-Tab window, causes the code sending events to InstallEventHandler(#callback) to lag.

At this point you'll get event logs like:

"handleEvent" "nil" "nil" "nil" 256 false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.down "nil" "nil" false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" "nil" "nil" "nil" 256 false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.up "nil" "nil" false
"handleEvent" "nil" "nil" "nil" 0 false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.down "nil" "nil" false
"handleEvent" __C.EventHotKeyID(signature: 1634497652, id: 0) AltTab.ShortcutState.up "nil" "nil" false

This indicates:

• The first Tab release is delivered after the second Cmd modifier is pressed.
  • This is intended behavior if you release and press Cmd before releasing Tab. But I think I released Tab before pressing Cmd again.
• The second Tab press (open popup and cycle windows) and release (stop cycling windows) are delivered after the second Cmd modifier is released (close popup).
  • This should never happen if events are delivered in the order they occur, since you cannot press Cmd-Tab when Cmd is released.

Because the popup is opened (Cmd-Tab) after the event to close the menu (!Cmd) is received, the menu never closes.

What caused the original bug?

I think the initial bug report (where "alt-tab" appears held for a second or so) is a variant where when the mouse sits above the popup while it opens, the Tab release event is delayed, and the app sees it as Alt-Tab being held for a second even if the user quickly released it. I don't know what causes "mouse sitting over Alt-Tab" to trigger shortcut processing delays on some machines sometimes, but removing AltTab from accessibility options temporarily fixes it

It's possible that (in my reproducer) the lag happens because of my logging code sending data into the XCode output log; the bug becomes harder to reproduce (I have to Alt-Tab much faster to trigger the ordering error) after clearing the log. Nonetheless the core event ordering bug is an underlying Apple footgun/bug (I don't know if they promise in-order event delivery), and the effects are consistent with behaviors I and others in this thread have observed. In particular, cycling a few windows is only explainable by AltTab.ShortcutState.up being delayed, and "menu remains open" can be explained by the same mechanism.

[lwouis]

Hi everyone,

Could you please test this local build?

I made the shortcut handling code more loose. It may help be more robust and close even when events arrive in the wrong order from the OS. I hope it doesn't cause regressions, so please share if you see any weird behavior.

Thank you everyone to help test this one out 🙇

Thank you @nyanpasu64 for your great analysis. Thank you for helping see this issue resolved. It's a tough one as it seems to happen only for some people and in some cases. It's probably the OS being busy in specific ways, resulting in the issue.

[nyanpasu64]

The build causes a new(?) problem where when I Cmd-Tab (I rebound from Alt-Tab) to an app, then press and release Cmd, it switches to the app I most recently cmd-tabbed to.

[lwouis]

@nyanpasu64 thank you for testing it 🙇

I wasn't able to reproduce the issue you mention. Could you please share the sequence of inputs you did? For example:

• Cmd down
• Tab down
• -> AltTab shows up on screen
• Tab up
• Cmd up
• -> AltTab hides, and a window is focused
• etc

[nyanpasu64]

• cmd
• tab (popup opens)
• release tab
• release cmd (focuses window A)
• click window B in dock (focuses window B)
• press cmd
• release cmd (focuses window A again, even though the popup never appeared and you never pressed Tab to switch windows)

[lwouis]

I was able to reproduce with these steps. Thank you!

[lwouis]

If I map the sequence from your logs, I see that it not in order indeed:

cmd down
cmd+tab down (from a tab down)
cmd up
cmd down
cmd+tab up [this should have happened one row before since cmd up happened]
cmd up
cmd+tab down (cmd down)
cmd+tab up (tab up)

What AltTab does for keyboard input is listen to 3 different API callbacks:

• CGEvent.tapCreate for modifiers changes (e.g. cmd up, cmd down, etc)
• NSEvent.addLocalMonitorForEvents for local key presses (local = when AltTab is the activate app) (e.g. pressing escape to close the switcher)
• InstallEventHandler for global shortcuts (e.g. cmd+tab down, cmd+tab up)

It never occured to me before that these 3 sources could come send events in a different order than the one that happened on the actual keyboard.

Now that I think about it, it's totally possible. These callbacks may be coming from different macOS subsystems, or uses different event queues, or receive different loads at different time.

You may think that we have a complex implementation. Why not use one source of events? That's because we support quite complex use-cases:

• The user wants to bind a shortcut with only modifers (e.g. cmd+shift; with shift acting like tab)
• We want to let the user use AltTab even when Secure Input (a macOS feature) is active

To support that, we have the current complex setup with 3 distinct sources of events.

I'm not sure if there is a way for us to support out-of-order events. If anyone wants to help, here's where event handling happens.

Thank you

[nyanpasu64]

The worst thing is that the original bug report (alt-tab acts held) seems more like a delayed tab release (hotkey), than an event reordering (which can result from delays). So there's nothing you can do in your app to detect and compensate for that issue. At this point I want to debug the actual library code that sends hotkeys to the app (eg. breakpointing AltTab and looking at parent stack frames), but I'm not planning on that yet.

[arya1106]

Perhaps I'm misunderstanding, but would it not be possible to just listen for modifier events from CGEvent.tapCreate as opposed to also listening for global shortcuts from InstallEventHandler? I believe that way you wouldn't have to worry about events being delivered out of order from different APIs.

i.e. you would check cmdDown && tabDown for cmd+tab down and cmdUp || tabUp for cmd+tab up

in which case the flow would look something like this:

cmd down
tab down --- equivalent to cmd+tab down from InstallEventHandler
tab up --- equivalent to cmd+tab up from InstallEventHandler
cmd up

[lwouis]

would it not be possible to just listen for modifier events from CGEvent.tapCreate as opposed to also listening for global shortcuts from InstallEventHandler?

InstallEventHandler is used because it's the only API working during Secure Input. More info here. It's a jungle, but as a result of our complex implementation, AltTab shortcut system is extremely powerful. More than any other mac app I've seen. I've looked at how other big apps (e.g. Contexts, Witch, Alfred, Spectacles, etc) are doing it, and we support the most flexible shortcuts, and work in the most cases. That's my understanding at least.

[lwouis]

Hi,

Could you please test this local build?

It may just be robust enough to handle some out-of-order cases. It doesn't have the issue of the previous local build.

Could you guys please try it out of a while and see if it fixes the issue for you?

Thank you 🙇

/cc @unodgs @dottedmag @jordantrizz @AlexeyKupershtokh @warrenseine @ankushagarwal @nyanpasu64 @maximvl @problame @EskelCz @AlabasterAxe @evanhammer @saitonakamura @samuelhwilliams @jebeaudet @letalumil @Joeyn1993 @RecuencoJones @xdanik

[nyanpasu64]

No issues so far, though the bug is intermittent so it's hard to say it's fixed.

I noticed that after pressing alt-tab, there's a few hundred ms delay before the popup appears? Probably harmless, possibly intentional, I think KDE delays the alt-tab menu appearing so quick presses won't flicker the screen, though the downside is you have to wait a bit before you can start scanning the list of window titles to look for one you want.

[lwouis]

@nyanpasu64 AltTab does exactly what you described, to avoid flickering. You can remove that delay or adjust it in Preferences > Appearance > Animations... 👍

[RecuencoJones]

@lwouis works like a charm so far! Thanks so much for fixing it!!

[warrenseine]

I'm also testing and I haven't encountered the bug.

[nyanpasu64]

On the test build, I got a stuck-open Alt-Tab window when pressing the shortcut when exiting fullscreen in a Bluesky video in Firefox (https://bsky.app/profile/ashleylynch.bsky.social/post/3lbfuhxufsc2x). I cannot reproduce this issue on demand. So it seems not 100% fixed, but I don't know what's going on in this build.

Maybe I should update to the latest program release (which supersedes the build?).

[koterpillar]

The new build is an improvement (Alt-Tab is no longer stuck open) but sometimes it takes from a few seconds to half a minute after a single Alt-Tab press (not holding either key, just a quick switch to the previous app) for the action to happen. By the time I'll have switched manually using Dock or other shortcuts so I'll be switched back to another random window (correctly, but not what I wanted anymore).

[lwouis]

@koterpillar how often does it happen? Can you reproduce it consistently, like within a few minutes? Is your machine under heavy load or normal load? Do you use Karabineer, BTT, or other keyboard remappers? Do you use the laptop keyboard or an external one? Which keyboard layout do you use (physical and software via Input Source)?

Thank you

[koterpillar]

Happens occasionally, seems to happen more when on battery power. When it happens it happens often.

The machine is under no particularly heavy load, but the baseline is VS Code (plus language servers), browser, terminal, Slack.

I use Karabiner, no other remappers.

This happened on the internal laptop keyboard, can't recall if also on external.

US English keyboard, en_AU layout.

[lwouis]

Thank you @koterpillar. Karabiner could be messing with the inputs. Could you try and confirm if the issue happens with Karabiner not running?
Thank you