Releasing modifier key doesn't switch to app if shortcut triggered during a space change

[frypf]

Mojave 10.14.6 / AltTab 6.1.0 (but also noticed in 6.0 and 5.3)

Describe the bug

If I use the keyboard shortcut to switch to an app on another space but then quickly press it again (having released all keys), the AltTab switcher window stays on the screen. I then need to use the mouse or repeat just the modifier to actually switch to my desired app.

Steps to reproduce the bug

I've played with settings, disabling other apps, different modifiers and even different keyboards (bluetooth and wired), and in every case this bug seems reproducible if the keyboard shortcut is invoked while the space switching animation is still in progress. I do use BetterTouchTool and Yabai, which I'd originally thought may be the cause. However even with these disabled the bug is consistent.

I hadn't noticed this in versions prior to the recent shortcut reimplementation - although I can't say for certain that this is related, as I wasn't looking for it at the time and I may just be more impatient or unsure of my app-switching decision making recently.

Sidenote

This app is awesome, thanks for persevering through all Apple's ill-documented nonsense to give us the functionality we'd actually want/expect when switching apps and windows!

[lwouis]

Hi @frypf! Thanks for sharing this issue!

It's probably a regression from the keyboard rework of v5 indeed. In v5, the keyboard inputs went from being gathered on a background thread, to the main thread. This is not on purpose, but a constraint that the carbon API has. It's possible that this threading change has subtle regressions such as this. I'll look into it.

Pressing AltTab during space animation is a nightmare to handle as you can imagine as screen is changing, active app and window is potentially changing, and it's over time. So we can conserve the contents we had before the switch, thus why i implemented to close and reopen the window on arriving at the new Space

[frypf]

Thanks for the update/clarification - I was conscious of the fact I'm probably taxing the app quite a bit when I'm indecisive like that. On a related note, would it be feasible to expose opening and closing the switcher window programatically - eg as a script trigger or similar? This way we could integrate better with things like BetterTouchTool, showing the window with the mouse/trackpad.

[lwouis]

would it be feasible to expose opening and closing the switcher window programmatically

It is already possible thanks to #458. You can bind any shortcut to mouse clicks, and select this preference:

For more scriptable flows, we have #371

[frypf]

Thanks, #458 seems to cover it.

Edit: Actually having reviewed this, it's almost but not quite what I was hoping for. Would it be possible to have the "then release" behaviour different for shortcuts 1 and 2? This would allow use of the mouse binding as discussed but without affecting the regular instant switching keyboard functionality. Let me know if this is unrealistic or worth moving to a separate thread. I realise it's a bit off topic from the original issue, and also that you're busy trying to get to the bottom of the test build issues from the other thread. And also that I've prob been bombarding you with requests and unsolicited opinions the last few days! 😬

[lwouis]

@frypf yes I thought about having the "then release:" preference be per-shortcut. If you read the ticket you will see this was my first proposal actually. Then during implementation, I thought that probably no user needs to have that much flexibility. The cost being more complexity for the user to understand such a flexible preferences UI and system.

Could you please open a ticket to discuss this further? Maybe some people actually would enjoy that. I would allow for example to bind the "Do nothing" to mouse shortcut, and the "Focus selected window" to keyboard.

[lwouis]

Regarding the original issue from this ticket, I think I found what was happening, and made a fix. Here is a test build.

Could you please tell me if that also fixes the issue on your machine?

[frypf]

Thanks for working on this, only tried it for about 30s so far but initially it seems to solve the issue. Now we can be as indecisive as we like 😂

Edit: It still fails to dismiss occasionally, but not every time as before. I'll keep monitoring and see if I can find more specific reproduction steps.

[frypf]

Okay it seems to work fine as long as I make a point of releasing the shortcut after the space transition completes. Previously that didn't matter, if the shortcut began during the transition the switcher would always hang around regardless of when I released it, even after the new space was fully visible. I'll play with it some more although this is definitely a huge improvement and more than likely something I can train my muscle memory to work around. It's certainly much more of an edge case now, thanks again!

[lwouis]

I found another completely different implementation that should behave smoother during space transitions. Could you please try it out and let me know and it performs on your machine?

[frypf]

Ok, I've had a play with both and the latest one definitely does seem smoother, although it was difficult to put my finger on exactly what's changed from a UX perspective.

With the earlier version (referred to as v1 from now on) I had noticed some occasional visual artefacts during the space transition (eg the space taken up by the switcher window retained what was displayed on the previous space until the transition was complete). This is often an issue with my machine's specs / taxing the WindowServer and I've experienced it infrequently in other apps before, so I wouldn't have necessarily put it down to AltTab. That being said, it happened every time I opened v1 and then invoked the switcher for the first time, then infrequently afterwards. With the newer version (v2) I've not noticed it as often, so this seems an improvement - although it does still happen occasionally. I had to screen record for ~8m30s to capture the gif below, and I've been making a real effort to tax AltTab with quick shortcut presses in order to test 😁.

With regard to the shortcut release timing, this seems to be tied to the apparition delay in some way. I normally have this set around 150-200ms, in which case it behaves as I described before, ie releasing during the space transition fails to dismiss the window but releasing afterwards it's fine. To test further, I set it to 0 on v2 and found that it mostly eliminates the problem, although maybe 1 in 20 times it fails to notice the shortcut at all. Interestingly, when I do the opposite and set it to the max 2s, then the switcher fails to dismiss every time unless I wait the full 2s. Only it's more confusing what's happening then because it also takes the full 2s to even appear onscreen, during which time I'm not pressing anything. And it's difficult to keep testing like that as it completely messes with workflow! The gif below gives an idea - I repeat the shortcut during the initial transition but release it almost instantly. I did try to use Keyboard Viewer to show my keypresses but only the modifier registered on it, possibly because AltTab is intercepting me pressing Tab (which shows up fine when not pressing the modifier).

I went back and did the same tests again on v1, and found that with apparition delay set to zero it was failing to register fast keypresses more like 1 in 10, so v2 is definitely more robust in this regard. Not sure how helpful any of this might be to you drilling down into the issue. I can live with zero delay, although I'd prefer to have a short delay rather than no delay precisely because of my general indecision and forgetfulness when switching between apps and not wanting to have the switcher pop up every time. However my findings may represent a more serious potential problem for others who use a longer delay as well as fullscreen apps / spaces.

[frypf]

Just a quick follow up, I hadn't even thought to compare to the original MacOS switcher behaviour when transitioning between spaces. I've realised that by default, if I invoke the shortcut before the transition completes it only works about 50% of the time anyway. (I'm guessing something to do with WindowServer again - it seems to work more often switching between 2 fullscreen apps as opposed to between a fullscreen app and a regular desktop space containing more than one window). So you've already vastly improved over the original functionality and speed - I think the difference is that under default circumstances the shortcut just fails silently. It was only the fact that the AltTab switcher window remained onscreen that alerted me to the fact that something was amiss, whereas before maybe I'd just assume computer slowness and hit the shortcut again. I don't even remember... I think using AltTab has actually made me more impatient in my expectations over the last month or so. And even more so after this run of testing!

Between that and the fact that I'm now pressing so unnaturally fast / often to test it, I'm beginning to see why no-one else has mentioned this issue. The relationship with the apparition delay probably still warrants further investigation, but in the meantime I should probably tell my fingers to chill and be more respectful of the limitations of my system!

[lwouis]

You first gif is a great example of when I'm stuck with technology. I've noticed similar issues, and we have the annoying #563 open. When these visual glitches happen, I don't know how to investigate further. There doesn't seem to be any documentation from Apple going into more details on the rendering pipeline. Is this just a glitch in their software like some GPU buffer not being emptied properly like when I was a kid and Windows 98 would minimize a fullscreen game, then I could "draw" on the screen by moving a window around. It was really cool. So are we seeing an OS bug here, are is it fixable through some API? I spent many hours recently looking at lower level APIs in macOS, but couldn't find anything that addressed this issue. There is also no literature online for these graphical glitches.

Regarding your point about comparing with the built-in app switcher: I'm shocked to realize that they just ignore the shortcut during transition. Basically AltTab provides a better UX than Apple... unbelievable. The app switcher has been in macOS for so long, how come they haven't improved on that UX.

[frypf]

"draw" on the screen by moving a window around

Ah, the good old days 😂 I'm definitely no expert, just been a user since 10.4 - although there were no Spaces then. I first remember experiencing similar glitches (and worse, the dreaded WindowServer crash) on 10.7 and 10.8, almost always when switching Spaces. My upgrade history has been sporadic as I tend to leave a system as-is once I have it set up as I like, although my previous one was 10.11 and I never really noticed the issues there. But then I was using TotalSpaces as I'd noticed Apple were starting to remove functionality from Spaces and add all sorts of forced slow animated rubbish all over the place.

I've noticed the glitching more on my current machine, but not exclusively with AltTab. I'm also aware that I've probably been asking more of this one graphically, and paying more attention than I did previously (attempting to learn about Swift and experimenting with NSVisualEffectViews, installing Yabai originally just to remove animations etc.), although even then not much more really. There must be users doing far more graphically intense stuff and experiencing these issues in a manner that's actually affecting their livelihood, yet like you I've never found any answers beyond "it's just WindowServer, what are ya gonna do 🤷‍♂️ ". Apple have never been the most upfront about admitting to the causes / fixes for issues, but it strikes me as really weird that nobody's shouting louder about it.

I'm realising none of my response is helpful to you beyond saying that from my point of view at least it's an OS thing that I've noticed for years... but then "it's just WindowServer, what are ya gonna do 🤷‍♂️ ". Oh wait, now I kind of see how this situation perpetuates 🤔.

Basically AltTab provides a better UX than Apple...

Yes. This. It's why I like your app 😂

[lwouis]

I think #563 is likely to be on AltTab side, as it was not happening in previous releases. It may be that some changes uncovered a bug in macOS because of speeding up AltTab, but it may just be a multi-threading or rendering lifecycle bug in AltTab.

For the your gif above, I don't remember seeing this before. Again, it may either be an issue with AltTab, or just macOS having a stroke sometimes due to some buffers being full or some cache being empty. I noticed for example after I implemented #566 that there is a new "jump" sometimes. I can reproduce it for example by switching quickly between 2 monitors. I would need to use my phone camera to document that, so not very convenient. But yeah, the first instantiation of AltTab on a new monitor will trigger a light visual jump. On my system at least. I tried hard to avoid it, but couldn't find a way. It seems to be that the window is displayed too early.

[lwouis]

I think I finally got a build that works well in all scenarios (I realized there were complex new scenarios when using 2 displays). All of these works great on my local machines:

• switching between 2 spaces on the same display
• switching between 2 spaces on different displays (UI should be remade for the new resolution)
• pressing the shortcut anytime during the transition (most of the time it should bring the UI on arrival)
• does not exhibit jitter/jank when bringing up the UI in and out quickly, even between 2 displays

[koekeishiya]

In case you did not know, it is possible to tell whether a specific display is animating (switching spaces), and you could just prevent the ui from being shown in the first place. I believe this is how the native cmd-tab switcher works. I haven't read the full discussion, so feel free to ignore if not relevant.

bool active_display_is_animating(void) {
    // retrieve the uuid of the display that currently has the active menubar,
    // replace with something else to check a different display.
    CFStringRef uuid = SLSCopyActiveMenuBarDisplayIdentifier(g_connection);

    // sanity check, has always returned a valid identifier for me
    assert(uuid);

    bool is_animating = SLSManagedDisplayIsAnimating(g_connection, uuid);  
    CFRelease(uuid);

    return is_animating;
}

[frypf]

I tried the latest build from this thread earlier and now also the latest from #563. In both cases I'm actually noticing the visual jitter more regularly now when I switch quickly between fullscreen apps and a regular Desktop Space (ie quicker than MacOS would allow without AltTab). Although I still can't be sure it's not partially down to my low specs and old monitor and the fact that I'm stressing AltTab more than usual for testing.

I just sent a report through after a crash triggered by restarting chrome via typing chrome://restart in the address bar. I was doing this as an experiment after noticing that sometimes when I experience the jitter having switched from fullscreen Chrome to Desktop 1 full of windows, AltTab still reports that Chrome is the frontmost app, while the menu bar clearly states that I'm in VS Code. That could well be down to Chrome itself or even the OS. It's a problem I'd noticed before I ever used AltTab, when initially setting up BetterTouchTool and using lsappinfo to determine the frontmost app.

Back to the issue at hand for this thread though, the later build from #563 seems the more robust of the 2 for handling the key-release, at least when I set the apparition delay to 0. Longer delays still produce the problems discussed earlier, albeit less frequently than when I mentioned them originally. Visual artefacts aside, all the other problems mentioned between this and #563 seem a lot more difficult to for me to find any reproduction steps - they're not completely eliminated, just a lot more sporadic.

When I read this back it all seems very anecdotal and increasingly difficult for me to quantify, so please let me know if any of it isn't useful or is sending you on a wild goose chase.

[lwouis]

I filmed a video regarding the Chrome issue as it's coincidentally connected to an issue I just solved (#571).

I'm actually noticing the visual jitter more regularly now still produce the problems discussed earlier Visual artefacts aside

Could you please clarify what type of visual glitch you're seeing? There are many different ways this stuff is glitching

[frypf]

Sorry I should have been clearer, by visual jitter/ artefact I'm referring to the same type as in the first gif I posted yesterday.

[frypf]

With regard to the apparition delay issues, I was talking about the relationship between key release timing and the switcher window failing to dismiss after space transitions.

[frypf]

Just watched the video - coincidental timing with the Photoshop thing indeed! I can't help but think I've caused you a whole load of unforeseen aggro with this ticket in particular, and as you say I'm inclined to think it's easily good enough for me. As we've discovered it's already more performant than the MacOS default, and I definitely don't want to hold up your development for what is an increasingly esoteric and edge-case scenario.

I was just trying to test as thoroughly as possible when I found the apparition delay / key release relationship so I thought that may be interesting for you to file away in case a user comes back later saying they use a long delay and have similar issues. The general consensus I get from reading the open (and closed) tickets is that I'm the only one who uses the switcher so indecisively, and even then it's most likely a habit I've gotten into as a result of the responsiveness of AltTab encouraging me to expect more from my system. That's no bad thing, as to me it just underlines the fact that your app has a better UX than MacOS itself. So as you say please don't delay other features and fixes trying to iron it out any further - I really appreciate the work you've put in on this ticket and the app as a whole. Thanks again man.

[lwouis]

@frypf no worries! I felt no bad intent/vibes from you at all. I appreciate your support in discussing and testing the issues 👍

I'll release the app soon 🥳 My only remaining worry is https://github.com/lwouis/alt-tab-macos/issues/397#issuecomment-686510287