search

lwouis / alt-tab-macos

Windows alt-tab on macOS
https://alt-tab-macos.netlify.app
GNU General Public License v3.0
10.53k stars 322 forks source link

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

Closed jsh9 closed 3 years ago

jsh9 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

Does it happen with the built-in MBP keyboard?

jsh9 commented 3 years ago

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

jsh9 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

Same observations as others: "sporadic" :-/

I've:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@jsh9 There are 2 distinct topics in this ticket:

I hope that clarifies where this ticket stands currently 👍

lwouis commented 3 years ago

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

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 commented 3 years ago

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

lwouis commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 7 months ago

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

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 commented 7 months ago

@yangmillstheory this issue here is closed. Are you perhaps experiencing this issue? https://github.com/lwouis/alt-tab-macos/issues/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 commented 7 months ago

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):

image

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

image

I'm not sure if this is the same issue as https://github.com/lwouis/alt-tab-macos/issues/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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

With that, I'm seeing

https://github.com/lwouis/alt-tab-macos/assets/2729079/db1be753-8d10-4b8a-ba4f-602f0baf0ebb

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!