Finder: Quick Look stops Alt Tab auto-focusing next window.

[frypf]

Describe the bug
Apologies if this has been posted before - I couldn't find anything directly related when searching the issues.

If the active app is Finder and I trigger Quick Look (either via menubar item or keyboard shortcut), then the next time I trigger AltTab, it sticks on the first result (ie. the main Finder window) and I have to repeat the trigger to advance to the next. This happens regardless of whether or not the Quick Look window is actually open any more.
If the Quick Look window is left open and you do switch away from Finder and back, AltTab's switching subsequently works as normal.

I don't need to see the Quick Look window within AltTab's results or be able to switch to it directly (as it's always on top), but this muscle memory disruption is frustrating. Is there any way of working around it?
I've also realised the same thing happens in any app when a dialog window appears, even after dismissing it.

This has been irking me for a while and I had been trying to get around it using Yabai rules, but to no avail unfortunately. It happens on both my machines (M1/Monterey & Intel/Mojave), regardless of whether Yabai is running.

Screenshots / video

720p.Screen.Recording.2022-09-27.at.14.01.36.mp4

Steps to reproduce the bug

1. switch to Finder
2. open Quick Look (or open then close Quick Look)
3. invoke AltTab keyboard shortcut
4. selected app only advances after repeating AltTab keyboard shortcut

[lwouis]

Hi @frypf,

Thank you for sharing this issue. In your video, I see the command+escape shortcut pressed in the middle of the video, instead of releasing tab to focus. That's a bit confusing. I don't have a mac for a few weeks, so I can't reproduce myself to see what's going on.

I've also realised the same thing happens in any app when a dialog window appears, even after dismissing it.

Could you share a video of that other scenario?

Finally, I wonder how other navigation tools from the OS react in this situation. What does Mission Control or the app switcher do in the same scenario with a Quicklook preview window open?

Thank you

[frypf]

Sorry that's my bad, I was using ⌘+⎋ because my fingers apparently anticipated needing to go back to Finder - but that's no good for a video trying to illustrate the problem! Apologies also for number of vids / length of the following post 😐.

I've also shortened my apparition delay, so hopefully this is more helpful:

720p.Quick.Look.AltTab.1.mp4

Next, AltTab's behaviour reverting to normal if Quick Look is left open and the app is initially switched by other means (eg. mouse or a second press of AltTab's Focus selected window shortcut). I then dismiss Quick Look - note the difference between doing so with the keyboard (AltTab subsequently behaves as normal) vs the mouse (AltTab again fails to advance to the next window).

720p.Quick.Look.AltTab.2.mp4

System nav interactions seem unaffected with Quick Look open.

720p.Quick.Look.system.nav.mp4

A few videos of similar behaviours with dialogs in various apps:

720p.VSCode.dialog.AltTab.mp4

720p.VSCode.dialog.system.nav.mp4

720p.Chrome.dialog.AltTab.mov

720p.Chrome.dialog.system.nav.mov

720p.Finder.dialog.AltTab.mp4

720p.Finder.dialog.system.nav.mp4

[frypf]

An attempt to summarise the things I noticed while making the above vids:

1. Switching into any app via the system switcher or Dock, or by exiting Mission Control, always seem to correctly raise any existing dialog or Quick Look window to frontmost.
2. Switching into Finder via AltTab fails to do this, although with VSCode and Chrome the dialogs were correctly given focus.
3. Switching out of an app via AltTab after a dialog or Quick Look opens always fails to advance to the next window, necessitating another press of Focus selected window to do so. After switching away and back again, AltTab's behaviour reverts to normal.
4. In VSCode and Chrome, AltTab reverts to selecting the next app in its list as normal after dismissing the dialog (either via mouse or keyboard). However with Finder, the erroneous behaviour remains until Finder is refocused after another app (after closing either Quick Look or dismissing a dialog).
5. In Finder, the existence of a dialog will cause any attempt to interact with any Finder tab (or separate window) to fail with an audible beep. An open Quick Look window does not inhibit interaction with other Finder windows.
6. VSCode and Chrome's dialogs seem tied to the individual app window generating them. Eg. the existence of a dialog in one Chrome window will not affect interaction with another Chrome window.
7. I don't know why the Quick Look window or dialogs are lighter grey after exiting Mission Control; this is a bit of UI strangeness I've only witnessed since using Monterey. As far as I can tell, it seems to be related to interactions between Mission Control and window layers / material / vibrancy. Either way, aside from the strange lighter shading of the focused window, it doesn't actually affect operation.

I have a couple of very vague ideas how to approach the issue (assuming anyone other than me has actually experienced it):

• Is it possible for AltTab to realise when a dialog or Quick Look has opened and update its own state accordingly? Eg. detect when an AXDialog or subrole: "Quick Look" (that AltTab would otherwise exclude from its UI) has become the main window or stolen keyboard focus, then update an internal flag linking this new window with the previous one until it is dismissed or closed. This seems like it would be pretty tough to implement consistently and still account for all the edge cases, eg. different dialog handling as described in 5 and 6 above.
• Alternatively maybe when invoking AltTab from within Finder, simply close any existing Quick Look window (as Quick Look is easy enough to reopen). For dialogs, leave everything as-is to remind (maybe encourage) a user to deal with the dialog before switching to another app. This is sort of how I've been treating the current behaviour. However this still leaves the situation in Finder where switch cycling is broken after dismissing either Quick Look or a dialog. I had been attempting to deal with these 2 scenarios via yabai, quickly activating SystemUIServer and then reactivating Finder whenever a window_destroyed signal is received from Quick Look / dialogs, thus resetting AltTab's list order. Obviously this is slow and creates a visual glitch - could AltTab force-update its state internally without needing to activate an intermediary app?

As ever, sorry for my longwinded explanation of yet another niche issue that no-one else has seemed to identify 🙏.

[lwouis]

@frypf thank you for the in-depth information, and sorry for the late reply.

Here are my thoughts on the matter:

I think we should separate the case of the dialogs and the case of QuickLook:

• Dialogs are windows attached to a another window. In that sense, both windows are couple and should be considered as one by AltTab.
• QuickLook is independant of the window that spawned it. You can then focus other apps and windows, and the QL window stays there, independent of its originator window.

For the dialogs, I think I've found a fix. You can test the build here to confirm if it works for you. The way I do it is that, if the currently focused window is not a window listed by AltTab (e.g. it's a dialog), then I check if the currently focused window has a parent, and if that parent is a window listed by AltTab, then I consider that this is the one that's "focused" as far as AltTab is concerned. In my tess, it fixes #2003 as well as the scenarios you describe in this ticket.

For QuickLook, I think the current AltTab behavior is actually correct. When you open QL, the Finder window loses focus. Thus it is the next window you may want to come back to, in the list of previous windows.

What do you think?

[frypf]

No worries on the delay front, you did say you'd be without your mac for a few weeks after all!

I've tested the new build and it seems to work perfectly for apps where the dialog is spawned within the window (VSCode, Chrome etc). However with Finder, the behaviour is unchanged and still presents as in this video. Weirdly though:

• on Mojave I can correctly switch away from Finder with a single press, but only for the first dialog spawned after AltTab is opened afresh. All subsequent interactions with that same dialog or any new dialogs exhibit the old behaviour exactly.
• on Monterey, the behaviour is exactly the same as the video.

I have since realised that some of the misbehaviours are further complicated by me using Finder exclusively in tabbed mode. If I have a second separate Finder window open, the cycling behaviour works as originally intended: ie. the first AltTab shortcut "full" press+release (of both key and modifiers) refocuses the last Finder window, and then a subsequent full press+release will correctly focus whatever is next in the list.
With only a single Finder window and multiple tabs, the focus cycling always sticks on the Finder window, only reverting to normal after I either focus a different window with the mouse or invoke a second AltTab "semi" press+release (of the shortcut key without releasing modifiers)

(Hopefully I've explained this well enough with regard to what I'm pressing and releasing - I attempted to capture another video to demonstrate the difference, but unfortunately KeyCastr doesn't differentiate individual presses and releases while the modifiers are still being held).

Regarding QuickLook, I can certainly see the logic to this, however in that case once the main Finder window has been focused (via AltTab, mouse click or whatever means) then AltTab's cycling behaviour should revert to normal. Currently, when using Finder in tabbed mode, this exhibits the same inconsistency as described above for dialogs.

I don't know how doable (or even desirable!?) it is to delve any further in to fixing this more robustly given that a lot of it seems to stem from macOS's poor native tab handling. I saw #2017 was posted earlier referencing yet another weirdness relating to tabs, and I also read with some amusement your snake pit comment and your reference to this excellent summary of the situation 😂. Hats off to you for persevering with working around Apple's "idiosyncratic" tab implementation for so long, but I fully understand if this ends up being a workaround too far!

[lwouis]

However with Finder, the behaviour is unchanged and still presents as in this video.

I dug into this use-case, and this Finder dialog's parent is not the window where the file is deleted. From a user's UX perspective it's a complete mess: The user can move the dialog and the window independently, like there are not attached/dependent, but when they click on the window, it refuses to focus, since the user should close the dialog. Keyboard navigation is also blocked.

Anyway, I think I found a better approach!

The idea is to consider that any "window" (could be a dialog) that's focused should be ignored, if it's not displayed by AltTab. That way QuickLook, dialogs, etc, don't mess with AltTab's focus order.

I've tested with QuickLook, different dialogs, and with the use-cases of #1044 as well, and I think the UX is great. @frypf could you please give this build a try, and tell me what you think?

[frypf]

Amazing, just tested and seems to work exactly as you intend: everything cycles and focuses as it should, whether switching into or out of a window. I agree this is definitely much more usable - especially with QuickLook, which rarely needs any direct keyboard input. If there was any way to return the focus to the input-blocking Finder dialog if it exists, in lieu of focusing the actual Finder window, (to allow dismissing/confirming via the keyboard) that'd be icing on the cake. But absolutely not a deal breaker if not.
I've just tried with an applescript-triggered dialog, attempting to delete a running app, or creating a folder in a protected location requiring admin approval, and now I realise I randomly landed on possibly the most frustrating example when I reported this issue. Apologies, I hadn't even thought to try other Finder dialogs than the one where I first noticed it happening, and it was just easy to trigger repeatedly when making the screen caps.

As always, thank you for your efforts - time to cull some signals from my yabairc 😅.

[lwouis]

@frypf I'm afraid I lost the plot on this ticket. I believe it may be fixed through the latest release which includes a lot of stuff.

Could you please try v6.49.0 and let me know if I can close this ticket, or if works should still be done, which work is left exactly?

Thank you

[frypf]

Think it's all working as you intend with 6.49. If there's an easy way to implement focusing a "blocking"-type dialog if it exists, that'd be awesome - i.e. the ones that cause

The user can move the dialog and the window independently, like there are not attached/dependent, but when they click on the window, it refuses to focus, since the user should close the dialog. Keyboard navigation is also blocked.

But definitely not a necessity (or even the original focus of this ticket). Either way, thanks for all the hard work man!