Trigger key behaves as if it was held, even though it was pressed just shortly

[nfekete]

I have Cmd+Tab set up as a trigger key. With moderate system load, many times when I press the trigger key combination and hold the modifier key, the trigger key is registered as if it was still held and the key repeat kicks in. Expected behavior would be that the AltTab grid opens with the previous window selected in the grid, i.e., the second element in the grid. Actual behavior is sometimes selecting a random element in the grid multiple positions away from the expected grid element, sometimes, scrolling to the very end of the list and stopping on the last element.

When this bug occurred, I had moderate system load with quite a few open windows, WindowServer constantly using about 30% CPU time of a core in a 12 virtual core (6 cores x HyperThreading) system.

I am running 6.7.0, so the new keyboard handling mechanism is in place. With the old keyboard handling I never experienced this issue. It feels as if the key release event was delivered delayed to AltTab or not delivered at all.

[nfekete]

Demo video. Note to interpret demo video: the interesting part is between 00:01 - 00:05. There, a single short press of Cmd+Tab triggers many forward movements in the AltTab grid. I do another Cmd+Tab at 00:07 - 00:11, but this time I hold Cmd+Tab down. Note the difference in the KeyCastr overlays in the lower left corner. When I hold the Cmd+Tab in the second instance, it displays a lot of repeated overlays, while in the first instance it only displays one, since it's just a short keypress.

[SoPat712]

This has happened to me too recently. +1 on this issue.

[lwouis]

What refresh rate do you have on your screen?

I just tested on a 240hz screen and the repeat rate is way too high. The reason is that I aligned it to the screen refresh rate. I'll replace it with a fixed / 60 instead.

Could you please try this preview build and tell me if that behaves better for you?

[nfekete]

I am convinced the issue I am facing has nothing to do with the monitor refresh rate. Maybe that is also an issue, but this is different. I use an external UHD screen which runs at 60Hz and there's additionally the screen of the 16" MacBook Pro (not sure about the refresh rate, but I guess it's similar). When the windowing system is not under load, everything runs nicely. When under load, the new way of handling keyboard shortcuts produces this behavior I described, quite consistently. I managed to trigger this behavior with almost every invocation of AltTab, when the windowing system is under load (WindowServer using constant CPU, which you can trigger with many app windows open). Key release events are apparently arriving late, sometimes very late, sometimes not arriving at all, meaning that AltTab scrolls to the very end of the window list in the grid in this case.

[frypf]

+1 from me too.

[lwouis]

Oh then it could be that the repeat timer i used has too much tolerance (tolerance saves on battery usage by letting the system trigger the timer not exactly when you ask it to, but with a tolerance), or that somehow the system is giving the thread which hosts the timer low priority, thus triggering the event later.

I'll look into that

[lwouis]

I just checked, and there is no tolerance, and docs say the default for a CFRunLoopTimer is 0. Furthermore, I have set the qos (Quality of Service) to the highest which is .userInteractive, so the OS is supposed to treat the key repeat timer with priority.

I'm not sure what's happening. I'll continue investigating

[lwouis]

Does the issue happen with backward cycling (i.e. alt-shift) as well as forward cycling?

[nfekete]

Does the issue happen with backward cycling (i.e. alt-shift) as well as forward cycling?

I never trigger AltTab directly with backward cycling. I trigger it forward cycling and maybe later do a few backward cycling steps if I overshoot. Is it even possible to trigger AltTab backward cycling? Because this issue happens when triggering AltTab, not after it's already open.

[frypf]

Just to follow up on my experience of this, I'm noticing it under slightly different circumstances (as detailed in #588): notably in my case though I've already released all the keys, including the modifier.

I've also noticed that when it occurs it makes it difficult to reliably select the correct window using the mouse as it keeps cycling through. And hitting the escape key (which used to hide the UI without switching), instead now always selects the currently highlighted window.

[nfekete]

Since many times I can see the selection changing in front of my eyes, with the AltTab grid doing a repaint in each of these grid position advancements, possibly at 60fps–certainly fast enough for me to see an absolutely fluid movement of the selection rectangle to the very end of the grid–, I would be very surprised if this was about thread scheduling. To repaint the grid really fluidly, that would involve a lot of CPU cycles, orders of magnitude more than what it would take a delivery of a key event. It feels much more like a missed event.

Strangely, some times AltTab pops up–after a short trigger combination keypress–with the selection stopped (i.e. not moving forward 60fps like crazy), but not at the second item in the grid–as you would expect–, but somewhere in the middle. That means that the key release event was certainly delivered. It feels like the position where it stops depends on the duration it took for the OS to bring up the AltTab grid. The appearance of AltTab in these cases feel delayed, like in those cases that were partially mitigated–but not entirely solved–by the thumbnail refresh being partially done in the background asynchronously. Could there be such a relationship? Do you have any part of the code where you calculate the number of key repeats based on timestamp deltas? If yes, that could very well be one part of this issue. The other part being, where the key release event seems to be missed entirely.

This issue looks and feels like a combination of two different issues, both possibly happening in a windowing system under load.

Sorry for the complex sentences, I know it makes a difficult read. I tried to simplify my thoughts about the issue as much as possible, but I couldn't think of a better way to describe what I am experiencing.

[lwouis]

Can you please try out this local build and tell me if it works for you?

[nfekete]

@lwouis the bug is still present. I had it less often though, but I cannot tell whether this is due to improved code or because I didn't push my system as much as when I originally stumbled upon this issue. I lean on the latter. EDIT: just as I posted this comment, the very next invocation of AltTab resulted in the 11th position being selected in the grid.

[SoPat712]

I'm having the same issue again even in the local build. The local build did manage to fix #603 somehow. The issue happens particularly often when my computer is slowed up with tons of apps running. Not sure if thats relevant, but I added it anyway. The laptop I mostly use alt-tab on is a late 2013 Macbook air, and it has 8 gigs of ram and 2? cpu cores.

[svenjacobs]

First of all thanks for the great application! 😃

I'm not really sure if this is related but I have the feeling that selection with Alt+Tab is quite sensitive. Sometimes I miss the window because I likely pressed Alt+Tab a few milliseconds too long. It would be nice to have a configurable "lock in" value that waits for the specified time until the next Alt+Tab is triggered. Imho it should behave more like the native Cmd+Tab switcher.

[lwouis]

Hi @svenjacobs!

AltTab uses the System Preferences > Keyboard values for the initial delay before repeat, and for the repeat rate once it starts repeating. I think it makes sense that way. It should be the same values as the default app switcher. Try modifying those and see what you like. You could also modifying these 2 values specifically for AltTab by using some command lines. Any setting in System Preferences can be applied to 1 app with different values basically. This is how Apple designed User Preferences. I didn't think it was worth the added complexity added to end-users to expose this.

Was I clear? I'm on the phone so hard to do a long reply with links and more details 😅

[lwouis]

Also i think this issue is done. I'm going to close it. Please let me know if the issue is still relevant. I assume it was fixed somewhere in the past month. (I'm talking about the OP, not some other issue)

[jaekyeom]

@lwouis If by done you mean the fix is released in the stable channel, I should say I'm still experiencing this issue (in version 6.9.0). Also, the OP's last comment says the issue was still present in the test build.

While I'm not sure if this can be completely fixed, can we have an option to turn off the key repeat feature, just like the older versions of AltTab, please? 😅

[svenjacobs]

Thanks for the reply @lwouis 😃

It should be the same values as the default app switcher.

It feels different and repeat is definitively much faster for AltTab than for the default app switcher.

You could also modifying these 2 values specifically for AltTab by using some command lines. Any setting in System Preferences can be applied to 1 app with different values basically.

I have no idea how to do this. Could you please explain? 🙏

[SoPat712]

@lwouis If by done you mean the fix is released in the stable channel, I should say I'm still experiencing this issue (in version 6.9.0). Also, the OP's last comment says the issue was still present in the test build.

While I'm not sure if this can be completely fixed, can we have an option to turn off the key repeat feature, just like the older versions of AltTab, please? 😅

I'm also getting the same issue in 6.9.0 with inconsistent triggering of Alt-Tab

[nfekete]

Please let me know if the issue is still relevant. I assume it was fixed somewhere in the past month. (I'm talking about the OP, not some other issue)

Unfortunately it's still present. I had to revert to an older version because of this issue.

[lwouis]

@SoPat712 @jaekyeom I'm wondering if you are all talking about the same issue from this current ticket. Do you both experience exactly the behavior that @nfekete showcased in the video above? The issue being:

• Hit alt-tab fast enough that there is no repeat of the tab key
• AltTab appears, but it start cycling through windows very quickly, as if tab was help, and even faster than what the speed would be if it was

I want to be sure that we are all talking about exactly these symptoms.

[lwouis]

@svenjacobs could you try playing with these 2 sliders in System Preferences > Keyboard?

Left one is how fast the repeat rate is when you hold a key. Right one is the initial delay when you hold, before it starts repeating.

[SoPat712]

@SoPat712 @jaekyeom I'm wondering if you are all talking about the same issue from this current ticket. Do you both experience exactly the behavior that @nfekete showcased in the video above? The issue being:

* Hit alt-tab fast enough that there is no repeat of the tab key

* AltTab appears, but it start cycling through windows very quickly, as if tab was help, and even faster than what the speed would be if it was

I want to be sure that we are all talking about exactly these symptoms.

Yes, I am receiving the exact same behavior at random times. I, like @nfekete have a ton of windows open, and it just instantly switches through every single one of my apps without stopping.

[svenjacobs]

@svenjacobs could you try playing with these 2 sliders in System Preferences > Keyboard?

Left one is how fast the repeat rate is when you hold a key. Right one is the initial delay when you hold, before it starts repeating.

Yes, changing these values chances the behavior of AltTab.

[frypf]

Just chiming in with another +1 from me, I'm still experiencing the OP issue occasionally on 6.9.0 (albeit much more intermittently than when first reported with 6.7.0).

I hadn't even thought previously to play with the global or per-app*^{see below} settings to see how AltTab reacts. I've since realised that AltTab only respects the settings with the Select next window shortcut. The Select previous window shortcut seems to retain the old value, even after restarting AltTab or the whole computer. This happens regardless of being set globally / for AltTab only, using a bluetooth / wired keyboard, having other input apps eg BetterTouchTool running / quit, or changing which keys are mapped for the shortcuts.

I don't know if (but somehow doubt) it's related to whatever's causing the OP issue, or something worth filing separately - it's hardly a dealbreaker in terms of functionality as you (rightly) can't invoke the UI directly with the backward shortcut. The OP issue happens so infrequently for me that I've not been able to gauge if / how turning the repeat off might affect it - which may help other users who are holding off on updating because of it.

Just thought I should report here as you'd mentioned it replying to @svenjacobs question. And also as I was previously considering asking if there's any way of turning off the key repeat entirely. The per-app setting would appear to be exactly that, subject to working consistently for forward- and backward-cycling.

*For anyone else previously unaware (like me 2 days ago), the settings can be changed per-app via the command line with:

• defaults write com.lwouis.alt-tab-macos KeyRepeat -int 6
• defaults write com.lwouis.alt-tab-macos InitialKeyRepeat -int 25
• The "useful" range for these values appears to be 1-120, where 1 is quickest. They can effectively be set to off by inserting a much higher value, like 30000. To disable repeating set the InitialKeyRepeat to 30000 (this is how the MacOS system achieves this functionality).
  
  

A quick gif to illustrate the behaviour: (I was going to use KeyCastr but thought it's press&hold behaviour was confusing for the issue at hand so please forgive the description)

1. hold the forward shortcut (⌘⇥)
2. release ⇥
3. hold the backward shortcut (§)
4. release all keys
5. change the setting
6. repeat 1-4 (This time I moved the mouse between 2 and 3 just to highlight the final app - the forward cycling doesn't repeat but the backward does.)

[svenjacobs]

*For anyone else previously unaware (like me 2 days ago), the settings can be changed per-app via the command line with:

• defaults write com.lwouis.alt-tab-macos KeyRepeat -int 6
• defaults write com.lwouis.alt-tab-macos InitialKeyRepeat -int 25
• The "useful" range for these values appears to be 1-120, where 1 is quickest. They can effectively be set to off by inserting a much higher value, like 30000.

Thanks, I didn't know this 👍 Maybe AltTab should offer an UI for these values? 😉

[lwouis]

Maybe AltTab should offer an UI for these values? 😉

It's an open question. Some apps for instance show an option to switch the app language (e.g. your whole macOS is in French, but you want that 1 app to show in English). Most apps though, only read the user's preferred language in the System Preferences, and display in that language, with no option to change it for that specific app. Is it a problem? Probably for a very small subset of users. Should AltTab expose an override for the system language, the dark/light mode theme, the scrollbar being always visible or auto-hide, etc, etc? It's an open question.

In this specific case, it seems you want keyboard repeat to be at a different speed only in AltTab. Don't you want the same repeat speed in all apps, so you can have it predictable and get used to it? How many other users want to customize that global preference? I could add additional UI to enable that more easily than through the macOS built-in terminal way. Is it worth the added complexity? If I added all preferences for all possible lever, the app settings would be 10 tabs and people would tell me to simplify it.

Preferences are a hard problem. Usually I wait for at least 2 people requesting one before considering it. I also put no spyware in AltTab, so I have no idea how people use the app, and what preferences they set in a statistical sense. Anyway, I hope I gave you some elements of answer and perspective.

Update: I realize now that maybe you meant to expose these, so people can disable key repeat all together? If I would, then I would expose a toggle to disable it, not a number people would have to set to 30000. However, I don't like the idea of exposing a toggle off instead of actually fixing the bug. It seems to happen for a small number of people. I feel the people in this thread have now 3 options: apply the workaround listed above to fix the case on their machine, try to help reproduce/understand the issue so it can be fixed for everyone else, or both.

[svenjacobs]

I see your point. I don't think apps should offer configuration for any preferences like language etc. but in case of AltTab key repeat is directly related to the user experience.

In this specific case, it seems you want keyboard repeat to be at a different speed only in AltTab. Don't you want the same repeat speed in all apps, so you can have it predictable and get used to it?

Not in this particular case. I want to have fast key repeat for my IDEs and editors but have it a bit slower for AltTab. As I said before - and I don't know why - key repeat for the default app switcher is definitely slower and doesn't seem to be related to the system setting. I immediately noticed this when switching to AltTab. The values are different than what I'm used to all the time.

Update: I realize now that maybe you meant to expose these, so people can disable key repeat all together?

No, not in my case. I just want to slow it down a bit.

[lwouis]

key repeat for the default app switcher is definitely slower and doesn't seem to be related to the system setting. I immediately noticed this when switching to AltTab. The values are different than what I'm used to all the time.

On my system, they are the same. Could you please share a video (at 60 frame-per-seconds if possible) so we can see it motion?

[frypf]

I want to have fast key repeat for my IDEs and editors but have it a bit slower for AltTab.

This is my ideal use case also, but it's a niche enough requirement that I wouldn't expect it to be implemented at the expense of extra programming effort, especially if there's a way around it as we've discovered.

Maybe AltTab should offer an UI for these values? 😉

From my POV, I'd vote for leaving it out and just setting via the CLI defaults rather than adding further complexity - as ever it's a matter of documentation. @lwouis is there anything we can do on that front to help? You've put so much effort into this and I see many issues filed and then closed after a single helpful reply from you, where someone doesn't understand some particular setting / added bit of functionality and you have to explain. A wiki would seem to be the way to go (and something I'd be happy to assist you on), but people are people and who even reads the instructions (😬 😆 )? And as the functionality is constantly evolving, where would we even start with structuring etc., not to mention providing language-independence / localisations like you've done in the app itself.

I was generally aware of user defaults either for System Prefs or for tweaking functionality and settings provided by individual apps, just hadn't put 2+2 together that you could apply the concept across the 2 domains like that. Well, I learn something new every day. Mostly from this repo tbh 😄 _{(Sidenote: that 30000 value is what is set by the system on the InitialKeyRepeat when you set Key Repeat: Off via System Preferences. This seemed counterintuitive to me at first, but thinking about it it provides the same functionality.)}

I feel the people in this thread have now 3 options

I've not noticed the OP issue yet since changing this setting yesterday, although it was pretty infrequent beforehand anyway. The only consistent thing when it happened previously was moderate (or higher) CPU load. Will keep an eye on it and report any further findings.

On my system, they are the same.

Same here, although I swear I remember the same behaviour @svenjacobs described prior to messing with the System Prefs and defaults over the last few days.

AltTab only respects the settings with the Select next window shortcut.

I've since tested a bit further and realised the default switcher exhibits the same ignorance of Key Repeat: Off on subsequent keypresses without releasing the modifier inbetween. However in this case it applies when pressing either ⇥ or ⇧⇥ while still holding ⌘, regardless of which I invoke first. Also, there seems to be some internal flag set upon showing the default switcher UI - if I keep holding ⌘ and press ⎋ to dismiss it, the behaviour is reset and the next keypress of ⇥ or ⇧⇥ doesn't repeat, but the following ones do. Other ⌘-based shortcuts don't reset the repeating in the same way.

I realise this is all very esoteric, doesn't require any fixing on your part and is probably unrelated to the OP issue. However, somehow with AltTab the forward-cycling just never repeats, indicating that AltTab is definitely handling things differently - leading me to wonder could the OP issue be related to ShortcutRecorder itself? Apologies if you've already considered / investigated that possibility, I'm just spitballing ideas.

[svenjacobs]

imho AltTab doesn't need a UI for adjusting key repeat if the defaults write "trick" is mentioned in the README or wiki 😃

[svenjacobs]

key repeat for the default app switcher is definitely slower and doesn't seem to be related to the system setting. I immediately noticed this when switching to AltTab. The values are different than what I'm used to all the time.

On my system, they are the same. Could you please share a video (at 60 frame-per-seconds if possible) so we can see it motion?

Okay, I have to correct myself. It seems that after playing around with the system settings the behavior of the default app switcher is now in sync with these settings. Maybe the switcher was using some old system default settings from a few macOS versions ago (I never changed the values) 🤷‍♂️

[lwouis]

documentation. @lwouis is there anything we can do on that front to help?

Yes of course! You can contribute to improve the website. There is a list of things that would be nice here already #211, but you could focus on adding a new "Manual" section with screenshots and explanations of the app. Maybe a video.

As you have mentioned though, documentation is unhelpful in general. The same kind of people who need it are the kind of people who don't read manuals, so it's an ineffective in my experience. A more productive approach would be something like https://github.com/lwouis/alt-tab-macos/issues/351#issuecomment-669676911. Preferences with more visuals, illustrations, clarity. Even then, only a fraction of users look at the preferences I think. Another layer that may reach those users is something around #85, which could be showing overlays/tooltips on first launch, or after N launches, to try to teach users about available preferences, and tips and tricks.

I hope I gave you some ideas of things that you can contribute if you're interested. Let me know if you'd like more details to get started 👍

I've since tested a bit further and realised the default switcher exhibits the same ignorance of Key Repeat: Off on subsequent keypresses without releasing the modifier inbetween

I can't believe the default app switcher actually has such a bug! AltTab however properly follows user preferences. You said "exhibits the same ignorance of...". I'm confused because on my machine if I turn off the repeat keys, AltTab never repeats in any scenario (unlike the built-in switcher). Could you please share a video to show what you're experiencing? I'm thinking that perhaps the specific shortcut or keyboard you use may be both the reason of this specific edge-case, but also the OP issue.

AltTab implements completely custom repeat. Normally pressing a key triggers an OS-level repeat. That is, the OS sends AltTab the key multiple times, with an attribute so that AltTab can know it's a repeat, not a actual key press, but still AltTab receives multiple events. That whole process does not happen with certain shortcuts, for example option-shift doesn't contain actual keys, but only modifier keys, so it doesn't trigger repeats at all. That's why internally in AltTab, I ignore all repeats, and trigger a manual repeating timer (which follow the OS timing preferences) to emulate a key repeat. It's all custom code. That's also for instance how I can stop the repeating once the user reaches the end (can be left, right, bottom, or top, depending on which direction they were moving).

[lwouis]

Okay, I have to correct myself. It seems that after playing around with the system settings the behavior of the default app switcher is now in sync with these settings. Maybe the switcher was using some old system default settings from a few macOS versions ago (I never changed the values) 🤷‍♂️

It's possible that the built-in switcher doesn't listen to changes while it's running, and changes would only reflect after it is restarted. Listening to user preference changes is extra work. I know that well since AltTab listens to many things, and it adds significant complexity to have the user be able to update things plug-and-play and have the app handle all sorts of exotic situations in a clever way.

[frypf]

You said "exhibits the same ignorance of...".

This is what I was attempting to show in the gif at the bottom of this post. Having played with EventTaps in the last few weeks I was vaguely familiar with how key events are conveyed by the system, ie a press, multiple presses with a repeat flag while held, and then a release. You mentioned the end-of-list behaviour, and this part actually always works (including when I've experienced the OP issue). I guess these OS-level repeats are what KeyCastr is actually showing, so I made a video to hopefully better illustrate.

Weirdly, updating the SysPrefs GUI Key Repeat setting to any value other than Off works correctly. Setting it to Off works for the forward switching but retains the previous value for backward. In this case the system actually doesn't touch the defaults KeyRepeat value: rather it updates the defaults InitialKeyRepeat value to 30000 and stores the current Delay Until Repeat value from SysPrefs (this time as an integer 1-6 representing the notches on the slider, just to add that extra bit of complexity fun) in a separate defaults "InitialKeyRepeat_Level_Saved". You probably know all this already, forgive me for piecing it together as I type.

Weirder still, clearing all 3 of these relevant global defaults with defaults delete…, AltTab's forward cycling reverts to the 'default' (standard? original? out-of-the-box?) global KeyRepeat value of (I think) 5, and InitialKeyRepeat of 35 (4 on the GUI slider) - obviously having just deleted them, there's nothing to query and confirm this. However, the backward cycling still retains whatever the last value was. Although in this case for both KeyRepeat and InitialKeyRepeat.

The behaviour is even more complex and difficult to describe clearly when I start setting per-app defaults for AltTab. It feels like I've hit on some edge-cases where it's missing a check on one defaults value when the other is updated, but my head hurts from trying to work out the full logic of it 😅 . And as to why it's only for the backward shortcut, I'm absolutely stumped.

I'm thinking that perhaps the specific shortcut or keyboard you use may be both the reason of this specific edge-case, but also the OP issue.

I'd had the same thought with regard to the bluetooth keyboard I generally use (Logitech K380), or possibly some weird interaction while BTT is enabled, or even just my choice of keys. However I've tested with a bunch of different combinations of all these factors and this repeat bug seems to happen consistently regardless of any of them - even with an Apple A1243 wired keyboard. The only exception to this is if I change to use a modifier+modifier shortcut for Select previous window then it behaves correctly.

TL;DR - For me, and only ever for the backward shortcut after the UI has appeared, AltTab is apparently:

• using the previous global KeyRepeat when Key Repeat is turned off via the GUI
• using the previous global KeyRepeat and InitialKeyRepeat when global defaults are deleted and no per-app defaults have been set
• using the current global KeyRepeat and InitialKeyRepeat when per-app defaults are set / updated / deleted and the global setting is not Off

Obviously there's a load of other combinations that I didn't test (or at least got too confused while doing so), and very few of them would reflect real-world usage. Does AltTab update its read of both values whenever either one is changed? It would also have been helpful for describing all this if Apple had named the defaults tool literally anything else 😂 .

Update: I don't tend to use the arrow keys with the UI so hadn't thought to test them before, but they exhibit the same erroneous repeat symptoms as I've described here for backward switching. So do hide (⌘H) and minimise (⌘M). The latter also seemed to crash the UI (spinning beachball and unresponsive to keys or mouse) as it tried to minimise and de-minimise the same windows over-and-over. I had to killall from the terminal, but AltTab didn't ask if I wanted to send a crash report when I reopened.

I've tested again and the repeating happens irrespective of changing them to non-standard keys. I'd already changed the quit and close shortcuts to incorporate an additional ⌥ and stop myself invoking them accidentally, you'll understand if I'm not eager to test those as well!

I'm wondering if UX-wise it's not better to exclude these 4 "window operations" shortcuts completely from repeating, regardless of the rate. Although if the problem is specific to my setup it's likely you'd already intended that to be the way it works.

[lwouis]

Closing as duplicate of https://github.com/lwouis/alt-tab-macos/issues/719. Let's continue the discussion there 👍