UI stays open after a Space transition, even when shortcut was released

[lwouis]

From this other thread:

Bringing in @MrBaseMax's comment from #587:

2. And this menu behaves like the option "do nothing" turned on (stays and waits for a click). Which is not. (Also "sometimes").

I can consistently reproduce this one in these circumstances:

• Invoke AltTab shortcut causing a switch to an app in another space.
• Invoke the shortcut again during the space transition, releasing it before the transition completes and before the "Apparition delay" time is complete.

[MrBaseMax]

6.4.0 negative. Still there
When i release a shortcut fast (before UI is shown), there should not be any UI at all, but it comes and stays. Works perfect when releasing shortcut after UI is shown. Face it switching windows of one app at one space.

[frypf]

Can confirm it doesn't happen for me either with apparition delay at 0. I know you mentioned (in the other thread) you only use a single space, but I've definitely only noticed this when switching apps triggers a space change (or from a fullscreen app to a non-fullscreen, or vice versa).

[lwouis]

The new release 6.7.0 should fix this issue. Closing this ticket. Let me know if the issue is not gone and I'll re-open it 👍

[frypf]

Sorry to say the issue is still there 😬
The behaviour has changed slightly, as it's now reproducible even with apparition delay reduced to 0.

[lwouis]

After investigating, I think what's happening is that during space transitions, macOS doesn't send some types of events to AltTab. Events are really complex in the current implementation, due to AltTab avoiding SecureInput. I noticed that during the transition:

• The RegisterEventHotKey are sent correctly, so alt-tab is triggered correctly
• The [InstallEventHandler+kEventRawKeyModifiersChanged] and [addLocalMonitorForEvents+.flagsChanged] events are not sent correctly, so alt being down is not triggered correctly

As a workaround, I forced alt to be down if the the RegisterEventHotKey event for alt-tab is pressed, as we know that one implies the other, so we can safely force it. In my tests, it seems to be fixing the issue.

I wish I knew why macOS doesn't send us these 2 specific kinds of events during Space transitions.

Here is a preview build. Could you please test it and let me know if that fixes the issue for you? 👍

[frypf]

It definitely reduces the problem, although it does still stay onscreen occasionally - maybe 1/10 times. Sometimes it simply stays onscreen as before, sometimes it manifests as #633.

[MrBaseMax]

The problem went completely away for me with 6.7.1

[frypf]

Just tried 6.7.2 and unfortunately still noticing the behaviour I mentioned in my last post - I think @MrBaseMax originally mentioned he'd only experienced the issue in same-space switches. I'm rolling back to 6.6.0 for now as I'm finding the key repeat aspect frustrating.

For the most part I've trained myself to switch less quickly (but still quicker than I would be able with the default MacOS switcher), so generally I don't encounter the original issue as often any more. On the occasions when it does happen then dismissing the UI isn't that much extra hassle: I usually just hit the modifier again to switch to my expected window or escape to cancel the switch. However when combined with the stuck repeating trigger mentioned in #633, it disrupts workflow pretty badly - I end up switching to the final window, regardless of whether I hit the modifier or escape.

Actually I've just noticed that in both 6.7.1 and 6.7.2 even without the key repeat being stuck and the UI just remaining on screen as per the original issue, hitting escape no longer cancels the switch - it always switches to the window highlighted in the list.

[MrBaseMax]

I face no troubles (mentioned in this bug) when switching windows of different spaces.

[lwouis]

I dug deeper, and it's more of a mess than I thought. During the Space transition animation, macOS will not report some keyboard events. Here is a some scenario I'm able to reproduce fairly consistently:

1. Normal scenario: alt+tab > Space 2 > alt+tab > Space 1

alt down > tab down > tab up > alt up > Space 2 > alt down > tab down > tab up > alt up > Space 1

2. Problem scenario: alt+tab > Animation to Space 2 start > hold alt > Animation to Space 2 end > tab > release alt > AltTab stays open

alt down > tab down > tab up > alt up > Space 2 > tab down > tab up > alt up

You can see here that macOS is not sending AltTab the alt down global event.

I realize now that my previous workaround couldn't work. I realize also that there is no way to compensate this missing event. It can impact the state of so many things, it's pretty crazy. The whole system relies on having every event arrive in order, as we maintain state of the keyboard to decide which shortcut was pressed/released and which action to take.

I'm pretty blocked on how to deal with this missing event from the OS during Space animation. I'm also thinking that it could be the root cause of #633 as well.

Note that I tried both these APIs: NSEvent.addGlobalMonitorForEvents and InstallEventHandler(GetEventMonitorTarget(), kEventRawKeyModifiersChanged), and both don't get the event in Scenario 2.

[lwouis]

I may have found a workaround I think. I'm excited as I think I've fixed multiple issues. AltTab works great for me in these scenarios:

• Switching between spaces, pressing the shortcut during Space transition animation, then releasing it
• Switching between spaces, pressing the shortcut then releasing it during Space transition animation
• Same as previous 2 scenarios, but between 2 different monitors, and with switch to another Space than the visible Space on the other monitor (this case was always difficult to handle)
• All of the scenarios + SecureInput is enabled
• All of the scenarios + Apparition Delay is > 0
• Shortcut is set to alt+cmd instead of alt+tab

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

[MrBaseMax]

I like. No issues yet

[frypf]

Wow, that's fast work, I was just reading your previous response and thinking of all the events to be missed, that's possibly the most frustrating and difficult to compensate for.

Tested the above scenarios and can confirm 1, 2, 5 + 6 seem much more robust / responsive, and the UI has correctly hidden every time. Can't comment on 3 as I've only got the single monitor. For 4, I'm never even sure if SecureInput is applicable or activated tbh - I tried clicking into a password field beforehand to see if it made any difference, but it didn't appear to do so: still hides consistently.

A couple of other observations:

1. If I switch really fast across spaces and back again, sometimes the shortcut still seems to fail. This seems more frequent switching between apps rather than windows within the same app. At first I thought this may be related to the old delay issues from AltTab's window sometimes "hangs" for 0.5 to 1.5 sec after choosing a window or cancelling #563, but manifesting differently now that the events are being transmitted / received correctly. Interestingly, I've only noticed the associated visual glitches from that issue once so far with this test version, whereas I could reproduce them pretty consistently before. I still suspect the UI delays may form part of this 'problem', although in reality please don't regard it as such: I'm unlikely to ever actually switch that quickly other than specifically for stress-testing AltTab 😅

2. However I also noticed that on occasion AltTab fails to reorder the list appropriately, displaying the previous window in position 1 despite the menubar reporting the correct current app. I've seen this a few times now, both when I have and haven't been making any specific effort to switch back and forth faster than normal, but only when switching across spaces. This comes across as a missed shortcut event as it's effectively switching to the same window I'm already in - but with my default apparition delay of 150ms I only noticed what was actually going on when it didn't switch on subsequent tries and so I held the keys to invoke the UI. This is how I also determined it's separate from (not-really-even-an-)issue 1.

   I tried disabling Yabai to make sure it wasn't something to do with my window snapping rules upon activation of certain apps. While that does make it even more infrequent, it still happens here and there. I know from my past experiments with BetterTouchTool and Yabai that sometimes switching apps across spaces (or activating apps directly) causes lsappinfo to report things inconsistently, so this may be unrelated to AltTab. But I'd not noticed it in 6.6.0, so thought I'd let you know for informational purposes at least.

[lwouis]

If I switch really fast across spaces and back again, sometimes the shortcut still seems to fail

Fail how? It stays open again, or it gets absorbed and you don't see the other app being focused?

on occasion AltTab fails to reorder the list appropriately, displaying the previous window in position 1

I think I've witnessed this a few times also when spamming keys like crazy. I can't make it happen slowly for instance. If you find reproduction steps for this let me know. Today I can't really reproduce it on purpose.

Ok so overall it seems like a great improvement, no? I think I'll release it

[frypf]

Fail how? It stays open again, or it gets absorbed and you don't see the other app being focused?

Sorry, the UI now always hides correctly but in these very rare circumstances the shortcut seems to be absorbed without focusing the next app. It really is very rare, only happening occasionally amongst multiple unrealistically fast key spams.

I think I've witnessed this a few times also when spamming keys like crazy. I can't make it happen slowly for instance. If you find reproduction steps for this let me know. Today I can't really reproduce it on purpose.

Weirdly, I'm having the exact same experience as you in that it seems even less prevalent today than when I tested yesterday. I think when it did happen on slow presses it was shortly after I'd witnessed it through spamming, so it seems unlikely to come up through normal usage. I'll keep an eye out if I do notice a bona fide pattern.

Ok so overall it seems like a great improvement, no? I think I'll release it

Definitely, hugely. Thanks for all the effort on this and the app overall - apologies for not mentioning that in my overzealous testing!