The shortcut key is not released after using it

[gradypark86]

Describe the bug

After I pressing the alt-tab(I set it cmd+tab) to switch windows, the 'cmd' key didn't released.
Because I often trigger some functions that require pressing the cmd key after switching windows(like scaling, but not 100% probability), which I do not press it.
So I open the virtual keyboard to watch the current key status, and find that after switching windows, the 'cmd' key is still highlight.
I try to change the shortcut key to ctrl+tab or opt+tab, then ctrl or opt will not be released.
However, when change the shortcut to double keys + tab, such as cmd+shift+tab, then there is no such problem.

Screenshots / video

2023-10-23.14.53.55.-.Compressed.with.FlexClip.mp4

Steps to reproduce the bug

Just press cmd+alt to switch windows.

Your environment

• AltTab version: 6.63.0
• macOS version: 14.0
• Other relevant info: using external keyboard: logi mx keys

[lwouis]

Hi @gradypark86,

I can't reproduce this issue. Furthermore, I spent hundreds of hours working on the key presses implementation, and at this point I'm quite confident that it works correctly.

My guest is that there is some software on your machine which is messing up the key events. Something like BTT, Karabineer Elements, or some Logitech software. It could also be the external keyboard that's creating the issue.

Could you please quit all software, and use the internal keyboard. Does the issue happen then?

Thank you 🙇

[gradypark86]

Thanks for your reply. I just tried quit some possibly relevant software but it has no effect.
Maybe I will install a new os on an external drive and test again these days. I will keep you updated if I find anything.
Thanks again for your great job.

[lwouis]

Hi @gradypark86,
Did you also use the internal keyboard, instead of the external Logitech keyboard?
Thank you

[gradypark86]

Yes, I tried it on a macbook and a mac mini, with the internal keyboard and an external keyboard. It's all the same.
But they have the same software installed, perhaps due to some software conflict.
So I will test it on a brand new OS and take a look.

[gradypark86]

Hi, I just installed AltTab on a brand new OS, and the problem still exsit. I set it to opt+tab this time, and it's more clear because the virtual keyboard will change to special characters when holding 'opt' key. Finally, I also tested the system built in cmd+tab, which is normal.
I also borrow another dell mouse and keyboard, it's failed too, sadly.

Is there any way to record a log or someting about this?

Thank you.

2023-10-24.11.06.36.-.Compressed.with.FlexClip.mp4

[gradypark86]

Great news! I just found that AltTab with the version under v6.7.3 is normal. This issue started to appear since v6.7.3.

[lwouis]

v6.7.3 is very old (2020-10-10). I'm surprised you went back in time that much to get rid of this issue. I wouldn't advise running a version from 3 years ago. We improved many aspects significantly since.

I was able to reproduce what you show on the video, with the Accessibility Keyboard. I think the Accessibility is bugged. I think AltTab correctly releases the key, but the Accessibility Keyboard fails to update its display. In your video, the first key next to tab is œ. I bet that if you press it on your physical keyboard, it will print q and not œ. This is what happens on my machine. This shows that the Accessibility Keyboard is incorrect and showing the current state of the modifier keys pressed. As far as the rest of macOS is concerned, the key was released.

What issue have you encountered? From your original post to the last one, you only show the issue with the Accessibility Keyboard. If I'm correct that there is a bug in Accessibility Keyboard, then you should face no issue in other apps.

Thank you

[gradypark86]

Hi, thanks for the detailed answer. In normal use, I've mainly found that two programs were affected.

1. Vivaldi browser. According to thier offical brochure, it has a feature :

Ctrl / ⌘ + Click on the URL to cut the link at the point you clicked and go to that page. For example, when you click on the word “blog” in https://vivaldi.com/blog/address-field-drop-down-guide/, you’ll be taken to https://vivaldi.com/blog/.

After I switch to Vivaldi and try to select a part of a URL, the mouse cursor truns into the hand shape instead of the 'I' shape, and can only click on the URL, not select it. I think this should be 100% triggered, maybe I will post the video latter. I don't have the mac with me right now.

2. Zotero. Sometimes switching back to Zotero, I just want to scroll the mouse wheel to page down, but it turns out to be scaling the pdf interface, which is the function of cmd+mouse wheel. The trigger rate for this scenario is not very high, but it does exist. I'm also thinking about why it can't be triggered every time.

The reason I use the Accessibility Keyboard is because it visualizes the current keystrokes. I think I will try v6.7.2 for a few days to see if it triggers the above events, and check if Accessibility is bugged. v6.7.2 and v6.7.3 behave differently on the Accessibility Keyboard, maybe some change to v6.7.3 made it happen. After that I will go back to the latest version, which I think is the best way to honor your years of nice work.

Thank you very much.

[lwouis]

Thank you for the detailed message~

I think I was partially mistaken. Thinking deeper about the issue, I think this is more accurate:

• When the user presses alt (or the custom modifier key(s) used by AltTab), it could be for another purpose than bringing up AltTab. So at this point, AltTab notices the press, but let other apps in the system see it.
• When the user, still holding alt, presses tab (or the custom key(s) used by AltTab), then AltTab knows that this shortcut is for AltTab. At this point, the tab down event is absorbed by AltTab. We wouldn't want the current app to receive a tab press, like being in TextEdit, and seeing a tab in your document.
• If the user presses escape, it closes AltTab, then when they release alt, we send the alt down event
• If the user clicks a thumbnail with the mouse, it closes AltTab, then when they release alt, we send the alt down event
• If the user releases alt to focus the window, it closes AltTab but doesn't send the alt down event

I thought we absorbed the event on purpose, to not bother the current app under AltTab. But looking the other cases such as clicking with the mouse, I find it inconsistent to do it in some cases and not others.

Maybe we should fix this and never absorb the event. I'll think about it deeper. I also need to check if it's doable code-wise, because the keyboard handling code uses undocumented 20 years old API just to achieve a smooth experience.

I'll update here later 👍

[lwouis]

I released the fix 👍

[gradypark86]

From my brief trial, this issue is solved.
Thank you for your enthusiasm and professionalism 👍