-
-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The window switcher advances several icons when alt+tab is pressed #719
Comments
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? |
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. |
Does it happen with the built-in MBP keyboard? |
Let me try it and report back. It may take me a few days because this is a sporadic error. |
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). |
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 |
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? |
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'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 |
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 |
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. |
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? |
Just to follow up on this issue. Is this solution:
your officially endorsed permanent solution, or just a temporary hack? Thanks. (Btw, this solution seems to work fine for me.) |
@jsh9 There are 2 distinct topics in this ticket:
I hope that clarifies where this ticket stands currently 👍 |
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 👍 |
@lwouis Good news, I hope that will help you to fix this serious bug, which broken experience |
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 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 |
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. |
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. |
@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 |
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? |
@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 |
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. |
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 |
With that, I'm seeing Screen.Recording.2024-01-28.at.21.59.36.movconsistently, 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! |
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.
The text was updated successfully, but these errors were encountered: