The event for the first key down (of ⌘) is sent, but never for any of the key ups, so basically QS doesn't know a key up has been made and that messes it up.
Not really sure what we can do here, since there's no way of knowing if the user is pressing ⌘⇥ - all we get is the very first ⌘ down and that's it.
Just to confirm: this is a v1.2.0 'critical' bug, and the pull should be against release?
I’ve just been rebasing release when master changes. I see no reason not to keep sending everything to master for the foreseeable future.
As for how serious this problem is, I don’t know. All things considered, modifier-only is still more reliable than it used to be, right? I never used it until I started testing your change. I have to admit I’m pretty addicted to just tapping Caps Lock (which is another ⌃ key for me) to call up QS. Since using that, this bug has been a very minor annoyance that I barely notice. Most times, I assumed I hadn’t hit the key hard enough. Now I guess I know better and maybe it’l be more annoying, but is it worth ripping out the changes?
As for a possible fix, you’ve looked much harder at this than I have, but here are a couple of ideas:
Since we see key down events, when we get a key down for the activating modifier, could we check somehow to see that ⌘⇥ is not currently down, even though we never saw its key up? Why is ⌘ immune?
Both QSController and QSInterfaceController have an appChanged: method that runs when switching apps. Would it be possible to do something there that “resets” the state of the event listener?
Unrelated to key events: Do we need bothappChanged: methods? They seem to do the same thing. The one in QSInterfaceController seems much cleaner. It matches on the bundle ID (instead of the name) and it can just hide the interface, instead of having to post another notification. Can we just drop the one in QSController?