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

https://github.com/lwouis/alt-tab-macos/assets/24422125/44cec264-affb-4058-b880-d87e60a9a14a

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 to 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 https://github.com/lwouis/alt-tab-macos/commit/3b0194d886fe31813fda6d319d5b743491b61b98, 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.

[warrenseine]

Can anyone reproduce the issue without having the mouse hover the UI?

I wouldn't be able to say. When it happens, I generally don't know where my cursor was. I'll try to be more attentive.

I have a gut feeling that it might have something to do with cpu load

OMG yes.

Just run yes > /dev/null & yes > /dev/null & yes > /dev/null & yes > /dev/null & (from this decade-old article) and you'll immediately reproduce!

[lwouis]

Hi,

I tried the yes > /dev/null & yes > /dev/null & yes > /dev/null & yes > /dev/null & command to stress the CPU. My AltTab works correctly. No drift in the selected preview.

@warrenseine so you reproduce it consistently with the following command? Do you reproduce this on the macbook internal keyboard, with no software running (e.g. BTT, Karabineer, anything to do with keyboard inputs)?

[lwouis]

Here is a build where I removed all the code related to repeating keys.

Could you please try it out, and tell me if the drifting issue still happens with that build?

Now for some technical details:

• When you hold a key, it repeats. For example, holding a will send a once, then after a kick delay, it will send a on repeat
• This is true of individual keys, but not shortcuts. When you hit command+c and hold both keys, it doesn't repeat.
• Furthermore, modifiers keys such as shift, don't repeat either.
• In order to provide a good experience for AltTab users, we add a layer of custom behavior on top of native key repeats. The goal is to have the user hold command+tab or alt+tab, and the tab key repeats. If they change the key to alt+a, we should also repeat if they hold a. There are many more cases that I won't detail here to avoid confusion.

[warrenseine]

so you reproduce it consistently with the following command?

When I tried, yes. It was quasi-systematic.

Do you reproduce this on the macbook internal keyboard, with no software running (e.g. BTT, Karabineer, anything to do with keyboard inputs)?

I didn't try. I was using an external wireless Logitech keyboard (but I've never had issues with repeated keys) and BTT, Maccy, Rectangle were running. I could try without.

I will first install the custom build and see what happens. I've just installed it and haven't reproduced the bug yet.

Thank you so much for investigating this with us!

[SamadiPour]

Update 2: I have been using v6.65.0 with macOS 14.3 for 1.5 weeks, and I haven't experienced this issue again. I haven't installed/removed any softwares since I opened this issue.

[Joeyn1993]

Here is a build where I removed all the code related to repeating keys.

Could you please try it out, and tell me if the drifting issue still happens with that build?

Now for some technical details:

• When you hold a key, it repeats. For example, holding a will send a once, then after a kick delay, it will send a on repeat
• This is true of individual keys, but not shortcuts. When you hit command+c and hold both keys, it doesn't repeat.
• Furthermore, modifiers keys such as shift, don't repeat either.
• In order to provide a good experience for AltTab users, we add a layer of custom behavior on top of native key repeats. The goal is to have the user hold command+tab or alt+tab, and the tab key repeats. If they change the key to alt+a, we should also repeat if they hold a. There are many more cases that I won't detail here to avoid confusion.

This has worked brilliantly to resolve the issue - this is my personal expected behaviour.

Are we able to make the difference between this and the standard build as a setting?

[RecuencoJones]

Here is a build where I removed all the code related to repeating keys.

Could you please try it out, and tell me if the drifting issue still happens with that build?

Now for some technical details:

• When you hold a key, it repeats. For example, holding a will send a once, then after a kick delay, it will send a on repeat
• This is true of individual keys, but not shortcuts. When you hit command+c and hold both keys, it doesn't repeat.
• Furthermore, modifiers keys such as shift, don't repeat either.
• In order to provide a good experience for AltTab users, we add a layer of custom behavior on top of native key repeats. The goal is to have the user hold command+tab or alt+tab, and the tab key repeats. If they change the key to alt+a, we should also repeat if they hold a. There are many more cases that I won't detail here to avoid confusion.

This build seems to be fine, I've been trying it with and without stressing CPU and I didn't experience drifting!

[warrenseine]

Yes, I concur. No problem so far with the custom build. And I also agree that I don't have the need for key repetition so an option to turn it off sounds like a good trade-off if we don't get to the bottom of the issue.

[lwouis]

The key repeat code dates from 2020. There was a tweak/improvement in 2022. The fact that people trying the build I shared above report not having the issue suggest that this key-repeat code was the root cause, or at least a catalyst.

This would suggest that the issue is a very old one, which happens on very few setups. I've never been able to reproduce it locally, which makes it very hard to debug.

I'll try looking into the key repeat logic. However, without being able to reproduce locally, it's very theorical work, and I can't confirm if a change works on my own, and will need people to try builds to let me know if it works for them.

I really wonder what is unique about the setup of everyone in this thread, which makes the issue manifest. It seems to be complex setups:

I was using an external wireless Logitech keyboard (but I've never had issues with repeated keys) and BTT, Maccy, Rectangle were running.

Anyone here reproducing the issue on the internal macbook keyboard, with the alt+tab shortcut, and no BTT/Karabineer/remaper turned on?