Alt-tab-macos: Can't use alt-tab shortcuts within virtualization apps

Created on 12 Apr 2020  ·  42Comments  ·  Source: lwouis/alt-tab-macos

Hi and thank you for the long missed, and imho more intuituve than MacOSX standard behaviour!

I have used the "old" v2.3.4 a long time with Mojave and it worked pretty flawlessly.

I'm using VNC.app a lot, connecting to a Win7 Machine.

With the old version I could just normal "move around" inside the VNC window and control it via keyboard shortcuts, although the ALT-TAB is bound in AltTap.app to the same keys as in Win7.

Never had a problem navigating inside the Win7 Windows via ALT-TAB keys

With the new version all the keys are mixed up in Win7 Window of VNC.app.
(all keys, like 123... or abc...z not just only the _control_ keys)

It seems to me, that the ALT Key is locked, like the CAPS-LOCK function.
(i.e. If I press ENTER in explorer.exe on a file, it opens its Properties instead of opening the file.)

When I quit AltTab.app, everything works fine....

So.... I thought, I could be clever and re-install the old version, but unfortunately, that trick did not work. Same creepy behaviour, also, I have the impression, some options from the preferences window are missing...they look strange to me...but that could only be my impression.

I'm sorry, I did not made a screenshot of my prefs from the old version, but the new one looks like this:

Bildschirmfoto 2020-04-12 um 18 10 56

Bildschirmfoto 2020-04-12 um 18 11 08
(sorry for german language screenshots, did not find a way to swtich to english, which I would also prefer.)

So, the question is, and before I talk about a feature request to turn off AltTab.app on special apps when on focus, I like to ask, if this is a known issue (found no open tickets) and how could I possible get this fixed? It worked great with v2.3.4

Thanks again for the great tool!

EDIT: I could make a video, but you don't see what keys I press, so its pretty useless, IMHO.

bug unreproducible

Most helpful comment

@lwouis You are right. I started AltTab -> Parallels. Parallels Tools are installed, too (if this makes a difference). If I first start Parallels it behaves like you say. It was late when I tried and didn't pay enough attention to the starting order.

But just right now I noticed if I am in a terminal in iTerm, AltTab doesn't work. It just sends a Tab to the terminal window. (AltTab started after or before iTerm, same).

All 42 comments

I recognized a similar issue using teamviewer or microsoft remote desktop. It feels like the key gets stucked.

@gitgetgot side-note: you said you would prefer to have the app in English. I thought I could open a ticket to add a language dropdown in the preferences. Then I thought for a moment, and reflected on the fact that almost no app offers that choice, and they all reflect the OS language.

You currently have you macOS in German. Why would you prefer having that 1 app in English? If you prefer English it seems like you would prefer English at the OS level too, no? That's my case for instance, I'm French but I have my laptops and phone set to English, and every app is thus in English.

To recap, there seem to be an issue of the hold shortcut on:

  • VNC Viewer (@gitgetgot)
  • Microsoft Remote Desktop (@ngocphamm, @PLanB2008)
  • Team Viewer (@PLanB2008)

It seems to be an interaction with virtualization / keyboard inputs forwarding to the remote systems. I don't have a remote machine to test this at the moment unfortunately. I'm thinking that it may reproduce in a VM hypervisor like VirtualBox or Parallel. I'll try testing with these apps.

Thanks for looking into this @lwouis. Please let me/us know if you want more info, or something to get tested.

I just tested with a Windows 10 VM in VirtualBox and I actually have the opposite issue: when having keyboard focus in the VM, I can type text inside Windows 10. However, when I press alt-tab, it displays AltTab from the host macOS on top of the Windows 10 VM.

I think means that AltTab captures the shortcut before VirtualBox has a chance to do it.

It's unfortunate because I don't have another machine I can remote connect to, to reproduce the issue and try to dig deeper :/

Oh wait maybe I can try to remote desktop into the VM? Not sure if it's supported but it's worth a try

@ngocphamm I use this very handy website to test inputs sent. Could you go there from the windows machine and press the main AltTab key (I think for you it's ctrl?) and share what the website prints? Also try pressing a simple key like e. What about if you go back to the macOS host at this point and do the same thing, what does it show?

I was able to use TeamViewer to connect to the VM. However, I see the same behavior as I described above: every key goes to the VM correctly except alt-tab which is intercepted by the host, and AltTab show on my screen instead of Windows's alt-tab.

Did you guys change some setting in TeamViewer? I can't reproduce

@lwouis So I'm not able to reproduce the issue anymore it seems. I've not used AltTab in a while (because of the issue), though.

This is what shows on that website on macOS. I hit Ctrl + Tab (the app's shortcut), and then e.
2020-04-19 at 5 20 PM

And this is what shows on that website on the remote Windows machine (using RDP). I hit Ctrl + Tab twice here though.
2020-04-19 at 5 23 PM

Seems like it works properly on macOS since the tab key doesn't show. I assume it's showing you AltTab UI at this point.

Then on Windows, same thing? I assume it's doing the same as for me: you see the AltTab UI on top of the RDP window?

Yup that's the behavior now @lwouis so it's working perfectly fine so far. I have updated the RDP app (Microsoft Remote Desktop Beta) multiple times since, so maybe it fixes itself 🤔 Or you actually fixed it.

Thanks for working on this great app!

@ngocphamm well I would say it's still not ideal that AltTab is showing instead of the remote windows alt-tab, but I would say that's a defect/limitation of the RDP apps since they should theotically find a way to intercept all inputs before any other app. It seems the way AltTab listens to keyboard events is higher priority somehow. I'm actually surprised because when you learn how this stuff works on macOS (spoiler: it's a terribly unmaintained/undocumented jungle, as usual from Apple), I would think that RDP app would use very low-level C APIs to get the events straight from the kernel instead of doing what I'm doing which is high-level.

@gitgetgot @PLanB2008 can you guys give some feedback? I'm thinking about closing this ticket since the only action at this point would be on the RDP apps, not on AltTab side.

@lwouis Yeah for me I can get around that limitation by setting AltTab to use Ctrl + Tab so I can use that for macOS, while using the normal Alt + Tab in the Windows machine.

Honestly I don't even care that much for the Windows one, because I use multiple monitors, and it's 2020 and Windows still can't figure out how to show that Alt + Tab window list in the "active" monitor. It always shows it in the monitor on the mac screen which is 99.9% hidden for me. Or it could be macOS, or the RDP app on macOS. I don't know.

Also, sorry for asking this here because it's totally unrelated. I think I found a couple issues, but I don't really know how to take a screenshot of the window list (when I hit the shortcut). Do you know how @lwouis ?

how to take a screenshot of the window list

The way I do it is with macOS built-in Screenshot.app. I set a 5s timer, then I have 5s to prepare the scene by hitting the shortcut and other adjustment like which thumbnail is focused for example

@gitgetgot @PLanB2008 can you guys give some feedback? I'm thinking about closing this ticket since the only action at this point would be on the RDP apps, not on AltTab side.

I have to look a littler deeper into this issue. I've to admit it didn't occur to me very recently. But this is also I result of not having to enter that many machines last week. I can test this a lot once I'm done with my programming tasks and back to supporting customers...

I would suggest to wait a little more before closing the issue, maybe I can provide some more input during the week.

@ngocphamm I use this very handy website to test inputs sent. Could you go there from the windows machine and press the main AltTab key (I think for you it's ctrl?) and share what the website prints? Also try pressing a simple key like e. What about if you go back to the macOS host at this point and do the same thing, what does it show?

I'm not sure, I could follow, but I tried my best...

I am on MacOSX now, and exited AltTab.
I opend VNC.app, connect to win7 machine and opened that link in FireFox.

Here is what I get:
1 ) ALT+TAB
2-5) e
6-7) CMD+SHIFT+4 to make this screenshot
Bildschirmfoto 2020-04-21 um 05 35 48

This is the output from Safari Browser on MacOSX:
1-4) ALT+TAB
5-9) e
10-11) screenshot as above
Bildschirmfoto 2020-04-21 um 05 47 04

Now, I started AltTab 3.12.0

Safari:
1 ) ALT+TAB
2-6) e
7-8) screenshot
Bildschirmfoto 2020-04-21 um 05 49 29

From within VNC.app on Win7 machine:
1 ) ALT+TAB
2) e
3-4) screenshot
Bildschirmfoto 2020-04-21 um 05 51 44

AltTab is still taking control over ALT+TAB inside Win7, I cannot use this combination to navigate thrugh the tabs.

@gitgetgot thank you sharing your experimentation! Indeed, it seems like you, me, and @ngocphamm, all experience the same behavior. The behavior being that AltTab shortcut is always intercepted by AltTab first, whether on the host or on the remote window.

I explained a bit of technical details above. In short I believe this is a limitations from the remote desktop apps. I don't see how AltTab could handle this.

Think about this: AltTab want to grab keyboard before other apps. If an app on your mac has alt-tab in it, you don't want that to trigger, otherwise if you switch to that app, you're "stuck" and can't use AltTab to switch to another app, as the app is absorbing the key events.

So AltTab grabs keys at a global level, before the apps. This includes the remote desktop apps it seems, according to our testing. I assumed they would have aggressive keyboard event listening, and grab before AltTab, but it seems they don't.

I can't imagine something we can do at AltTab level to concede events to Remote desktop apps, but not to other apps. If you guys can envision how, please share :)

Thanks for the explaination, the strange thing is, as I wrote in my initial post:
"I Never had a problem navigating inside the Win7 Windows via ALT-TAB keys"
It worked flawlessly before the update. Now, even downgrading won't work (for whatever reason)

My workflow was like this:
I used AltTab to navigate via ALT+TAB through the MacOSX tabs.
When I hit the VNC.app, I navigated inside Win7 with the same ALT+TAB keys.
When I want to "go out" of VNC/Win7, I just use CMD+TAB (the normal MacOSX keys for switching tabs)
After that, I just could use ALT+TAB again to see those nice images of tab-content.

Somehow its not working anymore and your explanation makes totally sense, although I don't understand, why it worked in the first place.

@gitgetgot the behavior you describe was on 2.3.4? You sure about this exact version number? I will check how the keyboard code was back then, then

I'm sure, because of the AltTab-2.3.4.zip on my harddrive which is dated 22.01.2020 and this version has no autoupdater, so I updated manually from a fresh downloaded AltTab-3.7.3.zip (12.04.2020) and that step seems not to be reversable (as I have no clue where the program stores its settings and what else I have to remove to _really_ have a clean uninstall).

what else I have to remove to really have a clean uninstall

The app has 2 things on the disk: the .app file, and the preferences.

The preferences are handled by the OS. You can view them by typing this in Terminal:

defaults read com.lwouis.alt-tab-macos

and you can delete them by typing:

defaults delete com.lwouis.alt-tab-macos

Could you possibly try to delete the preferences, and run the 2.3.4 version on your machine, and share with us the exact behavior you experience in VNC.app?

nice, thanks.

unfortunately, this

The preferences are handled by the OS. You can view them by typing this in Terminal

is only valid for the new version of AltTab.
The 2.3.4 seems not to have preferences stored as you described:
Bildschirmfoto 2020-04-23 um 20 31 38

I was able to delete the prefs, when 3.7.3 was installed, but no prefs were created by AltTab, when I installed 2.3.4.

As you see in my Screenshot, I already have changed some Options (and restartet AltTab 2.3.4), so prefs should be written to disk, but where?

Oh my bad! I completely forgot that back in v2, preferences were stored in a custom JSON file! Sorry about the misinformation. You should be able to find it here:

cat ~/Library/Preferences/alt-tab-macos.json

and delete it with

rm ~/Library/Preferences/alt-tab-macos.json

@gitgetgot did you get a chance to re-try the old version and see what behavior you get inside VNC.app?

Here is the list of apps users have reported, that can't use the in-VM alt-tab shortcut because AltTab triggers first:

  • VNC Viewer (@gitgetgot)
  • Microsoft Remote Desktop (@ngocphamm, @PLanB2008)
  • Team Viewer (@PLanB2008)
  • Citrix Workspace / Citrix Viewer (@skupfer)
  • VirtualBox (@lwouis)
  • Parallels (@skupfer)

I would like to hear opinions on how we should handle these. Here are is the approach I can think of: When alt-tab is pressed, AltTab checks which window has keyboard focus. If it belongs to one of the app above (we hardcode the list), it doesn't trigger and passes the shortcut through to the app. A big downside is that switching to any window of these apps "traps" the user as they can't invoke AltTab to switch windows.

We could potentially make a better UX by only doing that if the window is fullscreen. Another option would be to detect if the focus is on the virtualized OS. That may or may not be possible using the Accessibility API, but I can tell already it would be specific to each app, and very hard to do.

That may also be a preferences since some people may not use alt-tab, or may prefer to be able to alt-tab from the virtualization app rather then within it. I'm thinking a checkbox, unchecked by default: "Disable AltTab shortcuts when using a virtualization app".

Also I'm wondering if we should do it for any shortcut, or only alt-tab. Some people may use cmd-tab or win-tab on Windows for example. Or someone may set AltTab to respond to alt-e.

Note that I have done a POC locally, and disabling shortcuts when a specific app is active is working fine. It works for: VNC Viewer, Microsoft Remote Desktop, Team Viewer, VirtualBox. (I haven't tested Citrix apps yet). I'm mostly worried about the UX before going any further.

For documentation purposes: it's possible to list current CGEventTaps using this code:

let n = 20
var list = [CGEventTapInformation].init(repeating: CGEventTapInformation(), count: n)
var count = UInt32.zero
CGGetEventTapList(n, &list, &count)
debugPrint(list)

This can show event taps order (order in the array is the order in which they get a chance to see the events). From that list, the tappingProcess gives the pid of the process tapping events. Here we could find if it's a virtualization app.

There is no way though to either change the order of other event taps. We can disable/re-enable to bump AltTab to the top/bottom of the list, but not bump only virtualization apps to get ahead. Even if we could, the UX is still not the best since users are trapped.

I can't imagine a good UX that let's both users switch in the host and in the guest. I think, in fullscreen, everyone would prefer getting the guest alt-tab. But in window mode, it seems like some people will prefer one way, or another. I can't think of a clever solution to satisfy all workflows.

I don't see a need to hard code the apps. Maybe there will be more in the future. Let the user decide how he wants AltTab to behave, which could be done with a simple blacklist.
In my case if I work in a virtual machine I want all my behaviour there. If I am trapped in there its for a good reason. If I would want to get out I use the specified host keys and could AltTab again like always.

a simple blacklist

Could you elaborate on the UI to update such a blacklist? Some issues I can imagine off the top of my head:

  • How do non-technical users find the bundle IDs which they need to identify the apps?
  • Do we provide a way to select a .app and grab the bundle ID from there?
  • How is the blacklist visually represented?
  • Do we make a new preference tab for this?
  • What if the list is long like 20 apps? Add scroll to navigate through it?

If I would want to get out I use the specified host keys and could AltTab again like always.

I'm not sure that's technically possible. It depends if the virtualization app sends a new event to the system when the host key is pressed. This needs testing. Also as I said, there is no easy way to differenciate the VM window from other windows of the virt-apps: AltTab would not trigger on the preferences window of these apps for example.

I thought I have read that you wanted opinions. I could have explained the idea of an blacklist a bit better, but I guess you already wrote how it could look like

Do we provide a way to select a .app and grab the bundle ID from there?

Actually quite a good idea. macOS does the same i.e. when creating keyboard shortcuts for apps.

How is the blacklist visually represented?
Do we make a new preference tab for this?

Good idea to be honest. Exactly what I thought of.

What if the list is long like 20 apps? Add scroll to navigate through it?

Uhm, yes?

I'm not sure that's technically possible. It depends if the virtualization app sends a new event to the system when the host key is pressed. This needs testing. Also as I said, there is no easy way to differenciate the VM window from other windows of the virt-apps: AltTab would not trigger on the preferences window of these apps for example.

Ok, this might depend on the app. But usually if I am trapped within an vm it doesn't even care about AltTab. As soon as I use the host key, I can make AltTab appear again because now I am working on the macOS level again. Just gave it a quick try in Parallels. Within my VM (Windows, not full screen) I can use cmd-tab or alt-tab perfectly fine. If I press ctrl+alt it sets me free and cmd-tab and alt-tab behave on mac os level again.

EDIT: So actually AltTab works like you described already. Except there is no blacklist needed because the cursor is properly trapped by Parallels already.

Just gave it a quick try in Parallels. Within my VM (Windows, not full screen) I can use cmd-tab or alt-tab perfectly fine. If I press ctrl+alt it sets me free and cmd-tab and alt-tab behave on mac os level again.

I think that's because you started Parallel after AltTab which put it at the head of the event taps list, which means it gets to intercept events first.

Could you try launching AltTab after Parallel, and see if it works the way you describe, still?

Actually, I just tried playing with the starting order on my machine, and also changing the CGEvent.tapCreate call to use tailAppendEventTap instead of headInsertEventTap. I can't see any change. The behavior on my machine is always that AltTab intercepts the event first and shows it's UI, which means the underlying app doesn't get the alt-tab.

@skupfer I don't understand how you got Parallel to display Windows's alt-tab. When I switch the "capture host inputs" toggle, it doesn't change anything.

@lwouis You are right. I started AltTab -> Parallels. Parallels Tools are installed, too (if this makes a difference). If I first start Parallels it behaves like you say. It was late when I tried and didn't pay enough attention to the starting order.

But just right now I noticed if I am in a terminal in iTerm, AltTab doesn't work. It just sends a Tab to the terminal window. (AltTab started after or before iTerm, same).

I tried with iTerm but can't reproduce: AltTab shows properly. You're saying that if you switch to iTerm, if sends just tab to the terminal? What if you switch back to another app, then it works? I can't imagine what's going on here

This is weird. So yes, if I AltTab to iTerm, it just sends a tab to the terminal if I try to AltTab again. If I switch to another app (cmd tab or swipe left/right) it works again. How can I help you finding out what's wrong? Any debug logs or whatever I can send you?

@gitgetgot did you get a chance to re-try the old version and see what behavior you get inside VNC.app?

Yes, but unfortunately, I couldn't reproduce the bebaviour I described in my initial post.

after removing

 rm ~/Library/Preferences/alt-tab-macos.json
 rm ~/Library/Preferences/alt-tab-macos-defaults.json

and setting the options to my needs, I can not navigate via alt-tab inside VNC.app

End of story. :-(

I'm not sure that's technically possible. It depends if the virtualization app sends a new event to the system when the host key is pressed. This needs testing. Also as I said, there is no easy way to differenciate the VM window from other windows of the virt-apps: AltTab would not trigger on the preferences window of these apps for example.

Ok, this might depend on the app. But usually if I am trapped within an vm it doesn't even care about AltTab. As soon as I use the host key, I can make AltTab appear again because now I am working on the macOS level again. Just gave it a quick try in Parallels. Within my VM (Windows, not full screen) I can use cmd-tab or alt-tab perfectly fine. If I press ctrl+alt it sets me free and cmd-tab and alt-tab behave on mac os level again.

EDIT: So actually AltTab works like you described already. Except there is no blacklist needed because the cursor is properly trapped by Parallels already.

I used to use VMWare Fusion and if I was trapped inside Windows in fullscreen, I could simply quickly press two times CTRL or something like that which unfocussed VMWare. I found this very easy to remember and very useful. Also, that function did not "waste" a real shortcut.

It is alreay answered and my opinions are similar:

a simple blacklist

* Do we provide a way to select a `.app` and grab the bundle ID from there?

exacty. just add a "+" in the blacklist and a "-", where "+" opens finder and let the user chose. Just like in the systemprefs.
Bildschirmfoto 2020-05-10 um 05 27 35

* How is the blacklist visually represented?

nice, clear and clean ;-)

* Do we make a new preference tab for this?

sure.

* What if the list is long like 20 apps? Add scroll to navigate through it?

sure. like the above screenshot. acutally, it should/could look the same.

I could simply quickly press two times CTRL or something like that which unfocussed VMWare

Again, it's all about who reads the keyboard first. If AltTab gets to read the 2 ctrl before VMWare, then VMWare will not be able to decide to either absorb into the guest OS, or pass-through to macOS.

If it decides to pass-through to macOS, it should pass it to, in order:

  • The other apps listening to keyboards, including or not AltTab, depending on the order in the list. See my previous comment.
  • The active app which is the app with keyboard focus.

@gitgetgot we discussed a UI that lets the user select .app to add them to a whitelist/blacklist. See another issue here is that some apps are messy and launch multiple processes. For example, Octave.app, once launched, starts another process called octave-gui. I've seen this with other apps like Citrix or enterprise garbage-ware. For these apps, the user wouldn't be able to download the .app file in /Applications as the bundle ID of that app would not be the right one. So what to do then, let user input text, and ask them to find the ID somehow? Not sure how to have a decent UX here.

I would like to ask people interested in this issue for their opinion 🗳️

I revisited all discussion in this ticket, and I believe the solution I outlined here is the best way forwards. It offers an out-of-the-box good experience with virtualization apps. Here are the core features:

  • hardcode the list of common apps bundle IDs
  • when the user is focused on a window from one of these apps, if it's fullscreen, and if one of AltTab's shortcuts is set to alt-tab, then AltTab should not trigger it and instead forward it to the app

I think it solves most real-world use-cases. We could also add, potentially in a second drop, a UI to manage the blacklist. We keep the default hardcoded common virtualization apps, but we let people update the list. What I really don't like with this idea, is that a lot of people will get confused thinking that this blacklist is about blocking which app have their windows listed in AltTab. Clarifying that without a wall of text seems difficult to me.

Please let me know if you agree with this path forward, then I'll probably implement it soon as it's not much effort to do, without the blacklist UI.

I've been working hard to find a solution for this ticket, but it's really complex.

I started hardcoding this list of bundleIds, tested locally:

"com.realvnc.vncviewer",
"com.microsoft.rdc.macos",
"com.teamviewer.TeamViewer",
"org.virtualbox.app.VirtualBoxVM",

Then I searched and found other people's lists and it gets more complex. Then I realize that some people may actually want AltTab to switch them from 2 fullscreen VMs for example, thus we shouldn't hardcode it.

So I explored the idea of the blacklist again. I thought I should add a new tab in the Preferences called "Blacklist". Inside we could have a list of apps, and maybe checkboxes next to each row: "Ignore AltTab's shortcuts while this app is focused" and "Don't list this app's windows in AltTab".

But I started asking myself what this list would consist of. It can't be .app in a folder, because these can be anywhere. You can start an app from the Downloads folder for example, or from your ~/Applications folder instead of /Applications. I thought it could display running apps then. These clearly exist, and are easy to query. We would just need to ask the user to run the app before selecting it from the list. But then I revisited this line of code from AltTab, to detect the Android Simulator:

private func androidEmulator(_ runningApp: NSRunningApplication, _ title: String?) -> Bool {
        // android emulator small vertical menu is a "window" with empty title; we exclude it
        if title != "",
           // NSRunningApplication provides no way to identify the emulator; we pattern match on its KERN_PROCARGS
           runningApp.bundleIdentifier == nil,
           let executablePath = Sysctl.run([CTL_KERN, KERN_PROCARGS, runningApp.processIdentifier]) {
            // example path: ~/Library/Android/sdk/emulator/qemu/darwin-x86_64/qemu-system-x86_64
            return executablePath.range(of: "qemu-system[^/]*$", options: .regularExpression, range: nil, locale: nil) != nil
        }
        return false
    }

As you can see, the Android Emulator is a weird case because the app has no bundleIdentifier. If we made a list of "running apps", as illustrated in here, it would not appear. Even if we forced it to appear somehow, clicking it would add which bundleIdentifier to the blacklist?

There are endless corner-cases. At the end of the day, I think I will go for this UI as a first pragmatic pass. It can be improved later, but this would improve the situation for most users, for reasonable dev effort:

image

This is weird. So yes, if I AltTab to iTerm, it just sends a tab to the terminal if I try to AltTab again. If I switch to another app (cmd tab or swipe left/right) it works again. How can I help you finding out what's wrong? Any debug logs or whatever I can send you?

@skupfer Turn off iTerm2`s Secure Keyboard Entry

Was this page helpful?
0 / 5 - 0 ratings