Alt-tab-macos: Keyboard shortcuts sometimes stop working (Secure Input)

Created on 11 Feb 2020  ·  95Comments  ·  Source: lwouis/alt-tab-macos

v2.3.2 often doesn't fire - Alt-Tab invokes the standard MacOS switcher, except releasing the keys doesn't dismiss the dialog. I need to click on an icon or press Enter to dismiss.
Alt keys is Cmd, Tab is 48, theme is MacOS.
MacOS Mojave 10.14.6

Normally restarting Alt-Tab does the trick, but lately it doesn't change anything.

bug need breakthrough unreproducible

Most helpful comment

@mindfulsource I waited a bit, then as everyone reported good results, I merged the PR and closed this ticket. You can go back to the main/public release now

All 95 comments

Hi @stevemartina-salesforce! Thank you for sharing this feedback!

It seems to be some kind of OS-level priority about who gets to register the global shortcut. I will say that the current implementation is naive, and exhibits some limitations: #133, #17, #50.

I would suggest 2 approaches:

  • If you want a quick fix: could you please investigate a bit more, and try to guess what the root cause is here? The Keyboard handling is pretty short. It's not the easiest though since it's a swift bridge over a C API. You may want to just put some breakpoints around that file and see how the code flows while you reproduce the issue.
  • If you can wait a few weeks: I'm waiting on https://github.com/Kentzo/ShortcutRecorder/issues/114 to be implemented so that I can replace the naive code with the robust ShortcutRecorder library. This will most likely fix any issue such as what you are experiencing here.

Same here

  • AltTab 2.3.4
  • Catalina 10.15.3 (19D76)

I'm on AltTab 3.2.1 now and Catalina 10.15.4, and the issue of not firing seems to occur after my computer wakes from sleep.

EDIT: looked through other issues, seems to be related to #176.

EDIT 2: I let my computer sleep overnight, and AltTab still works this morning... maybe it's not related to sleep.

@kungpaogao I tried also to sleep/wake and it didn't stop AltTab from working.

I think there is a big lack of clarity as to what behavior is exhibited with this issue.

From @stevemartina-salesforce, I understand that he presses the AltTab shortcut, but AltTab doesn't show up. Instead the built-in app-switcher does. Is AltTab opened at this point? I could imagine it crashed for example, which would explain why the built-in app-switcher is showing instead. That wouldn't explain why releasing the cmd key fails at that point. That could be a second, different issue, like AltTab not properly releasing global shortcuts on crash for example. It seems suspiciously similar to https://github.com/lwouis/alt-tab-macos/issues/175.

@kungpaogao is the above behavior exactly the same for you? Could you elaborate on the symptoms you see? I would really like to understand if AltTab is still running or if it crashed.

I tried assigning the same shortcut as the app-switcher, starting/stopping AltTab, sleeping/waking my machine, etc. I also tried binding a global shortcut using System Preferences > Keyboard > Shortcuts after I start AltTab. I wanted to see if maybe the way it works is "last come gets the shortcut". That could explain the issue as the system may sometimes re-grab the global shortcuts for some reason, maybe after a wake, maybe on restart, etc, and that would mean AltTab doesn't respond to it anymore. "Unfortunately", I never got any problems. The shortcut works all the time for me.

Update: another possibility is an interaction with the Accessibility permissions. I say that because if restarting AltTab doesn't fix the issue, it may be that the accessibility permission has some issue. Is the app running after restart, or quitting instantly? Is the checkbox there in the System Preferences > Security & Privacy > Privacy?

Yah, I'm having a hard time reproducing the bug within the past few days. I'm honestly not sure what triggered it. It occurred on an older version, but then I updated, and maybe it occurred because I had to reset the Accessibility permissions after the new install (which I now have).

Best case, it just doesn't occur again :)

HI @lwlouis,

Sometimes randomly Alt-Tab stops triggering, i.e. it doesn't show up any
more. I can still see it's active in the notification area. Very rarely
closing it from the menu and restarting seems to work, but I haven't
noticed a pattern.
When I close it Alt-Tab works normally as per vanilla MacOS, and when I
start it again most of the time it still doesn't trigger, but releasing Cmd
still fails anyway - I have to press Enter or click on an icon to
dismiss the OOTB switcher.

I'm sorry I can't be more helpful but I'm not much of a MacOS user - I use
linux whenever possible and have to use a MBP for work as it's a company
standard. I don't really know much about the ins and outs of MacOS once
you move away from vanilla *NIX (e.g. I don't know Swift or AppleScript)

Thx -

Steve Martina

On Wed, 1 Apr 2020 at 10:05, lwouis notifications@github.com wrote:

@kungpaogao https://github.com/kungpaogao I tried also to sleep/wake
and it didn't stop AltTab from working.

I think there is a big lack of clarity as to what behavior is exhibited
with this issue.

From @stevemartina-salesforce https://github.com/stevemartina-salesforce,
I understand that he presses the AltTab shortcut, but AltTab doesn't show
up. Instead the built-in app-switcher does. Is AltTab opened at this point?
I could imagine it crashed for example, which would explain why the
built-in app-switcher is showing instead. That wouldn't explain why
releasing the cmd key fails at that point. That could be a second,
different issue, like AltTab not properly releasing global shortcuts on
crash for example.

@kungpaogao https://github.com/kungpaogao is the above behavior exactly
the same for you? Could you elaborate on the symptoms you see? I would
really like to understand if AltTab is still running or if it crashed.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-607097806,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANDR27PZYIZSLKKWCYKAVRLRKLYQZANCNFSM4KS6U36Q
.

@stevemartina-salesforce are you on the latest version now? If not, could you try it, and see if the issue still happens to you? It seems upgrading fixed it for @kungpaogao.

Another thing you could do is check in the System Preferences > Security & Privacy what's listed, and potentially removing/adding back.

I've just downloaded v3.4.0, it looks great! I think the latest I tried
before this was v3.1.3, I think it wasn't firing at all and I reverted to
the previous known "mostly working" version.

I'll let you know if v3.4.0 exhibits the same odd behaviour. I'll give it
a few weeks and if I don't see it I'll consider the issue fixed.

Thanks for all your work, this is a lifesaver for me...

Steve Martina

On Fri, 3 Apr 2020 at 08:43, lwouis notifications@github.com wrote:

@stevemartina-salesforce https://github.com/stevemartina-salesforce are
you on the latest version now? If not, could you try it, and see if the
issue still happens to you? It seems upgrading fixed it for @kungpaogao
https://github.com/kungpaogao.

Another thing you could do is check in the System Preferences > Security
& Privacy what's listed, and potentially removing/adding back.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-608259728,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANDR27M4NOVRVGG22B7FN6TRKWARNANCNFSM4KS6U36Q
.

Hi @stevemartina-salesforce! Do you think we can close this issue now, or have you seen it happen again?

I was going to ping you to let you know it seemed resolved, but then it
happened again on Thursday. I suspect it might have something to do with
being unplugged / replugged into a docking station? Not sure if it's the
monitor changes or maybe a keyboard being added/removed but it happened
again, and restarting didn't help.

Steve Martina

Senior Technical Architect

Commerce Cloud B2C Services | CSG EMEA Services

Mobile: +393429959196

https://www.salesforce.com

On Sun, 3 May 2020 at 17:43, lwouis notifications@github.com wrote:

Hi @stevemartina-salesforce https://github.com/stevemartina-salesforce!
Do you think we can close this issue now, or have you seen it happen again?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-623129319,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANDR27KW5OJFZ7CJRGG63I3RPWGINANCNFSM4KS6U36Q
.

Oh! Dynamically adding/removing keyboards! That's a use-case i haven't explored in depth! It's possible that registering keyboard inputs as we do for the shortcuts is specific to the active keyboard, and that switching to another keyboard means we need to bind again.

I'll experiment locally with keyboard, mouse, and display, being added and removed in the middle of using AltTab. I think that may be the root cause, and could affect also mouse and display. Update: I experimented with mouse, keyboard and displays connecting/disconnecting, and AltTab reacts perfectly to all scenarios.

I just tested with my external bluetooth keyboard and connecting/disconnecting it doesn't affect AltTab at all. Interestingly, I can use AltTab with the built-in macbook pro keyboard, or the external bluetooth keyboard, or both at the same time like holding alt on one and tab on the other. This makes me think that there is an OS layer converting keyboards inputs to events, and we subscribe later on the stack at the events level which is independent on physical keyboards used.

To recap, things I have explored without reproducing the issue so far:

  • Going in-and-out of sleep.
  • Settings a shortcut in System Preferences > Keyboard > Shortcuts after AltTab is running. The hypothesis here was that it would take precedence over AltTab's.
  • AltTab crashes and the shortcuts binding is "stuck". I have AltTab crashing very frequently when I develop it, and I could never reproduce the issue.
  • Connecting/Disconnecting external keyboards.
  • Removing the Accessibility permission while AltTab is running.

I'm a bit out of ideas on what could be triggering the issue here. Especially since it persists through AltTab being restarted.

One thing that may help: @stevemartina-salesforce could you please try following the instructions I wrote here? There is a link to a debug build of AltTab which logs keyboard events. You could run that build locally, and when it gets stuck next time, open Console.app, press the shortcut, and share here what is printed.

I've also experiences this, rare but it happens.

My unscientific impression was this happened when I was "faster then light" at times switching between windows/apps. Happened also to HyperSwitch countless of times.

I'll pay more attention next times about the details.

I re-read this whole thread here, and to be honest I'm not 100% sure that we are all talking about the same issue. The descriptions given are a bit unclear to be honest.

Could you please record using Loom or some other easy to use tool to share video capture of your screen next time a similar issue happens? This way I can review the footage and maybe get a clue at what's happening. Right now I'm pretty much stuck because I have actually never seen it happen, the descriptions are pretty fuzzy as to what the behaviors are, and I tried every step-by-step here to reproduce and it didn't.

It always happens in the worst possible time where I can't just stop and and analyze it to deep :-( [i.e. during work]

Last time, CMD-tab was not recognized at all. Even stopping and starting (!) AltTab did not fix it. Eventually after "some time" it suddenly just worked again (same happened to HyperSwitch I was having run in CMD-~). I did not reboot to fix it, it simply "cured" itself.

I know, this is even less then you asked for, sorry!

@mfn i'm starting to wonder if this issue is related to AltTab. You say that it affects HyperSwitch as well, and most importantly, that it happens when AltTab is not running. When AltTab is not running, there should not be any interaction with the OS.

I'm thinking that you may have some keyboard disfunction. Are you using an external keyboard, or is it a built-in macbook keyboard perhaps?

On macbooks, there has been lots of talks about defective keyboards for instance. Dust could get stuck behind the keys and prevent them from working properly.

Do you think this could be the issue here? This or another global app (I use Karabiner for instance to remap my keyboard)

that it happens when AltTab is not running

Hmm, wait, I didn't say that. Or at least, didn't meant to :)

CMD-tab falls back to its default OSX behaviour, using only the built-in app/window switching capabilities. Sorry if this wasn't clear.

I.e. closing AltTab and starting it again did not immediately fix it. It just happened to work after "some time" again (minutes, not hours).

Are you using an external keyboard, or is it a built-in macbook keyboard perhaps?

External! Connected via USB (2?) via adapter to USB-C

On macbooks, there has been lots of talks about defective keyboards for instance. Dust could get stuck behind the keys and prevent them from working properly.

Ah yes, but the key-press it's working, it's just AltTab (and HyperSwitch) not picking it up 😄

@mfn It seems to me that the issue you describe is very different from the OP. We may want to make a new ticket to distinguish these. There may even be more than 3, because some of the descriptions here are a bit hard to visualise.

Now about your specific case, it's pretty mysterious. It may be a macOS issue where the queue of apps listening has some issue that fixes itself after a few minutes? Pretty much impossible to investigate without more data :/

@lwouis First of all, thank for the great app.

I see the same behavior as @mfn

  • most of the time everything works fine
  • At some point Alttab no longer works. When the key combination is pressed, Mac OS reacts with the default behavior of the key combination. This applies to both the internal and external keyboard. For me there is no indication when this will happen.
  • Restart of altab is not fixing the problem.
  • At some point everything works fine again. Again for me no hint what is fixing the problem

I just released v4.0.0 which I believe fixes this issue. I closed the ticket, but please if you encounter the issue again after upgrading, comment here and I'll re-open the issue immediately 👍

I've upgraded to v4 and the symptom immediately happens I'm afraid.

On Mon, 25 May 2020 at 19:51, lwouis notifications@github.com wrote:

I just released v4.0.0 which I believe fixes this issue. I closed the
ticket, but please if you encounter the issue again after upgrading,
comment here and I'll re-open the issue immediately 👍


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-633667200,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANDR27LS7Q2UBETHFCUTQILRTKVWZANCNFSM4KS6U36Q
.

I can confirm. Same here. Happened again...

That's sad news. I was convinced thread explosion was the issue as i could reproduce that part locally with many windows open.

Could you guys use the built-in feedback form to send a debug profile here? That way we can see if something is up with your local environment like same version of macOS or something.

Another point: could you help me understand the symptoms? Currently, when the shortcut stop working, how is the app? Is it still running? Can you open the preferences or click "show"? You partially answered these questions already, but it's useful to go through them again for this new v4 i think as it may look similar but actually be a different bug.

Anyway thanks for helping the investigation! I never see this issue locally unfortunately

I'll see what I can do about the debug profile - this is my work laptop and
we're pretty strict (paranoid++) on security.

The symptoms:

  • It's as if the AltTab app weren't there at all (I get the OOTB
    switcher)
  • AltTab is still running and I can right click on the icon in the
    notification are and click "Show", and your switcher shows correctly

    • It doesn't seem to affect the "not triggering" symptom in any way

      (it doesn't magically fix the issue, and still doesn't trigger with the

      keyboard)

  • In terms of this issue, I've not noticed significant differences
    between versions, although subjectively I would say older versions were
    more prone to displaying the symptom

FWIW, it magically started working again since my last email.

Thx for all your work on this, BTW. As far as I'm concerned, your app is
the MacOS switcher. When it stops triggering and I see the standard
switcher I know productivity will dip until your app kicks in again.

Steve Martina

On Tue, 26 May 2020 at 10:23, lwouis notifications@github.com wrote:

That's sad news. I was convinced thread explosion was the issue as i could
reproduce that part locally with many windows open.

Could you guys use the built-in feedback form to send a debug profile
here? That way we can see if something is up with your local environment
like same version of macOS or something.

Another point: could you help me understand the symptoms? Currently, when
the shortcut stop working, how is the app? Is it still running? Can you
open the preferences or click "show"? You partially answered these
questions already, but it's useful to go through them again for this new v4
i think as it may look similar but actually be a different bug.

Anyway thanks for helping the investigation! I never see this issue
locally unfortunately


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-633882232,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANDR27OZX6AWDRZ2RXNUXITRTN35RANCNFSM4KS6U36Q
.

Based on your symptoms, then it must really be the OS event tap that starts sending the app the keyboard inputs. I asked ShortcutRecorder maintainer if he knew what could be the reason and he said that if the app takes too long to respond then the OS may disable the tap. However in v4 i reworked the code so that it returns the event to the tap extremely fast and does the work asynchronously. It was not doing much work anyway even in v3. I handled events asynchronously from v3 i believe.

Furthermore, there is code to detect that the tap was disabled and reenable it immediatly.

How this happens on your system is a mystery to me, and i don't see how to investigate that without you running the app in xcode locally and poking around the code with breakpoints and logs to see what is happening.

Only alternative i can imagine is that i make a local build of AltTab in which i add a bunch of logs near the tap code, and then you share those logs here next time it happens and we may get clues from that?

Oh and thanks for the encouraging words!

I think it's a reasonable explanation - I did notice that very rarely
nothing happens when I trigger AltTab with the keyboard shortcut. It's
possible it's not responding within a set time, and then the OS no longer
delivers events to it.

Having said that, most of the time there is no obvious pattern.

Steve Martina

On Tue, 26 May 2020 at 11:44, lwouis notifications@github.com wrote:

Based on your symptoms, then it must really be the OS event tap that
starts sending the app the keyboard inputs. I asked ShortcutRecorder
maintainer if he knew what could be the reason and he said that if the app
takes too long to respond then the OS may disable the tap. However in v4 i
reworked the code so that it returns the event to the tap extremely fast
and does the work asynchronously. It was not doing much work anyway even in
v3. I handled events asynchronously from v3 i believe.

Furthermore, there is code to detect that the tap was disabled and
reenable it immediatly.

How this happens on your system is a mystery to me, and i don't see how to
investigate that without you running the app in xcode locally and poking
around the code with breakpoints and logs to see what is happening.

Only alternative i can imagine is that i make a local build of AltTab in
which i add a bunch of logs near the tap code, and then you share those
logs here next time it happens and we may get clues from that?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-633922426,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANDR27MBSCSNV7FOQI4BTJTRTOFKFANCNFSM4KS6U36Q
.

This happens to me fairly often still as well, will send a bug report as
soon as I can and reference this issue.

Happy to install debug builds as well if I can help.

On Tue, May 26, 2020 at 4:30 AM Steve Martina notifications@github.com
wrote:

I think it's a reasonable explanation - I did notice that very rarely
nothing happens when I trigger AltTab with the keyboard shortcut. It's
possible it's not responding within a set time, and then the OS no longer
delivers events to it.

Having said that, most of the time there is no obvious pattern.

Steve Martina

On Tue, 26 May 2020 at 11:44, lwouis notifications@github.com wrote:

Based on your symptoms, then it must really be the OS event tap that
starts sending the app the keyboard inputs. I asked ShortcutRecorder
maintainer if he knew what could be the reason and he said that if the
app
takes too long to respond then the OS may disable the tap. However in v4
i
reworked the code so that it returns the event to the tap extremely fast
and does the work asynchronously. It was not doing much work anyway even
in
v3. I handled events asynchronously from v3 i believe.

Furthermore, there is code to detect that the tap was disabled and
reenable it immediatly.

How this happens on your system is a mystery to me, and i don't see how
to
investigate that without you running the app in xcode locally and poking
around the code with breakpoints and logs to see what is happening.

Only alternative i can imagine is that i make a local build of AltTab in
which i add a bunch of logs near the tap code, and then you share those
logs here next time it happens and we may get clues from that?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-633922426
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/ANDR27MBSCSNV7FOQI4BTJTRTOFKFANCNFSM4KS6U36Q

.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-633968281,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB4CUJWG5GBSYGN56YGCYSTRTOR5FANCNFSM4KS6U36Q
.

Here is a release build I made locally. It has the log lines to try and understand what's happening on your machines: AltTab.app.zip

Could you please run this, and next time the issue manifests, press some of the shortcuts a few times, then grab the logs from Console.app by searching for AltTab there?

For reference, here are the additional log lines:

private func keyboardHandler(proxy: CGEventTapProxy, type: CGEventType, cgEvent: CGEvent, userInfo: UnsafeMutableRawPointer?) -> Unmanaged<CGEvent>? {
    os_log("keyboardHandler1: %{public}@, %{public}@, %{public}@",
        CGEvent.tapIsEnabled(tap: eventTap!), type, cgEvent)
    if type == .keyDown || type == .keyUp || type == .flagsChanged {
        os_log("keyboardHandler2: %{public}@", NSEvent(cgEvent: cgEvent))
        if let event_ = NSEvent(cgEvent: cgEvent),
           // workaround: NSEvent.characters is not safe outside of the main thread; this is not documented by Apple
            // see https://github.com/Kentzo/ShortcutRecorder/issues/114#issuecomment-606465340
           let event = NSEvent.keyEvent(with: event_.type, location: event_.locationInWindow, modifierFlags: event_.modifierFlags,
               timestamp: event_.timestamp, windowNumber: event_.windowNumber, context: nil, characters: "",
               charactersIgnoringModifiers: "", isARepeat: type == .flagsChanged ? false : event_.isARepeat, keyCode: event_.keyCode) {
            let appWasBeingUsed = App.app.appIsBeingUsed
            App.shortcutMonitor.handle(event, withTarget: nil)
            os_log("keyboardHandler3: %{public}@, %{public}@", appWasBeingUsed, App.app.appIsBeingUsed)
            if appWasBeingUsed || App.app.appIsBeingUsed {
                return nil // focused app won't receive the event
            }
        }
    } else if type == .tapDisabledByUserInput || type == .tapDisabledByTimeout {
        os_log("keyboardHandler4: %{public}@", CGEvent.tapIsEnabled(tap: eventTap!))
        CGEvent.tapEnable(tap: eventTap!, enable: true)
        os_log("keyboardHandler5: %{public}@", CGEvent.tapIsEnabled(tap: eventTap!))
    }
    os_log("keyboardHandler6: %{public}@", CGEvent.tapIsEnabled(tap: eventTap!))
    return Unmanaged.passRetained(cgEvent) // focused app will receive the event
}

and

shortcutActions[controlId] = ShortcutAction(shortcut: shortcut, actionHandler: { _ in
    os_log("actionHandler1: %{public}@, %{public}@", controlId, App.app.appIsBeingUsed)
    let isShortcutInitiatingTheApp = ["previousWindowShortcut", "nextWindowShortcut"].contains(controlId)
    if isShortcutInitiatingTheApp {
        App.app.appIsBeingUsed = true
    }
    os_log("actionHandler2: %{public}@", isShortcutInitiatingTheApp)
    if App.app.appIsBeingUsed {
        let isShortcutClosingTheUi = ["holdShortcut", "cancelShortcut"].contains(controlId)
        if isShortcutClosingTheUi {
            App.app.appIsBeingUsed = false
            App.app.isFirstSummon = true
        }
        os_log("actionHandler3: %{public}@, %{public}@, %{public}@", isShortcutClosingTheUi, App.app.appIsBeingUsed, App.app.isFirstSummon)
        DispatchQueue.main.async { () -> () in shortcutsActionsBlocks[controlId]!() }
    }
    return true
})

I'm not sure if this helps, but as soon as I installed and opened the debug version it started okay, I could edit my preferences.

However, as soon as I pressed the keyboard shortcut, or Menu --> Show the app instantly crashed. I never actually saw the Alt+Tab UI overlay show up, only the Mac OS default one appeared.

I captured the logs, hope these are useful still. Happy to try another version/steps as well.

157-debug.txt

@nathang21 sorry about that! 🙇‍♂️ I thought os_log had a decent API, and also it compiled so I thought it was correct. Turns out I was far from putting working log lines. I've updated the log lines, and tested locally. Now I can confirm it works correctly and doesn't crash the app.

Please use this build instead:
AltTab.app.zip

New version worked great. I had trouble reproducing, although while the console was open, performance was not ideal when rapidly switching windows for a couple minuets. Seperate issue though, might not be much that can be done there.

Logs are here if they are helpful. Will continue using the debug version for a few days to see if I can get better repro.

157-v2-debug.txt

Hey @nathang21, just to clarify: you couldn't actually reproduce the issue of this ticket while recording the logs you shared above? If so, there is not much use to look at them i'm afraid. I need to see what logs come out when AltTab stops responding to shortcuts.

Regarding the performance issue, could you please compare with the regular production build? That would help us learn if it is an issue specific to the ad-hoc build i shared here. In that case it could be that logs are adding overhead. I doubt that, but who knows

Hey @lwouis you were correct I had trouble reproducing so feel free to ignore the previous logs.

It hasn't been happening as often, but I did just have it happen once this morning, and I grabbed the console logs right after.
157-repo.txt

@nathang21 thanks for sharing these logs! They are showing the symptoms indeed. Just compare them with the previous logs you shared. It's immediately apparent that something is wrong.

I noticed some log error from ShortcutRecorder inside, so I asked a question to the main maintainer.

When the logs start, the issue seem to already be happening. Could you share the logs before that, before 8:58:37? Basically, there are no actionHandler lines towards the top of your logs file. I would like to see from the last actionHandler, what happens so that these stop happening.

Also which shortcuts did you set for AltTab? Specifically this line:

image

Unfortunately I have restarted since then, so it looks like all the logs are gone.

  • I will try and repo again, and ensure I gather more logs.

Here are my key mappings.
Screen Shot 2020-06-10 at 6 46 37 PM

I dug a bit deeper in your logs, and it seems that the only times you pressed tab was in either of those combinations: control+tab or control+shift+tab. There are standalone presses of command, but it is never combined with tab.

I'm wondering if this is not an issue with some other app you use to remap your keyboard. I know I use Karabiner-Elements myself to remap control to command. It seems to me based on the logs, that AltTab is listening correctly to keyboard events, but that it's receiving shortcuts for which it is not set to react (i.e. control-tab and control-shift-tab) thus it's normal that it doesn't appear.

Woops I totally forgot to mention that, I should have thought about it. I am doing the exact same thing, via Karabiner-Elements to remap controlto command.

I can attach Karabiner-Elements logs next time as well if that would be helpful.
Screen Shot 2020-06-10 at 7 17 08 PM

Oh! That's your problem then! These rules are the issue. Not sure how rules order/priority work, but I can imagine, if they are run in order, your 3 rules have a logic bug where you remap control-tab to command-tab, then reverse it, then the 3rd rule does nothing.

Here is my setup that works, if you want to swap control and command (ignore the first line, which I like on the laptop keyboard):

image

That doesn't explain why the issue happens randomly for you though. Maybe right after your restart Karabiner-Elements?

That doesn't work for me unfortunately, but I think you're onto something about the rule order/hierarchy.

For context, I want to have Command + Tab for switching applications (via AltTab), and Control + Tab for switching tabs within an Application (aka chrome tabs etc.). Thus I want to swap the keys yes, but also separately configure those shortcuts which results in this odd looking config.

I've taken your options and tweaked them to my setup (see below). Will see if this works better, and report back.
Screen Shot 2020-06-10 at 7 46 54 PM
Screen Shot 2020-06-10 at 7 47 15 PM

@stevemartina-salesforce @joeberlin123 @mfn @kungpaogao @kingfisher77 how about you guys? Are you using some software to remap keys as well?

If not, could you please run the version I shared here, and share the logs from Console.app when the issue happens? This ticket is the last remaining real bug in AltTab, and I would be thrilled to either close it as nothing to fix, or to find the root cause and fix it.

Actually, since replying the first time and then updating, I haven't run into any issues with AltTab failing to trigger.

Thank you for the hard work, and hopefully others' issues are resolved!

EDIT: I don't use any remapping software.

@lwouis I'M not using software to remap keys like Karabiner. Now I installed the Alttab version with more debug logs. I'll send you the logs when the behavior starts again next time.

@lwouis Since ShortcutRecorder uses os_trace to log, it's better to use log stream --level debug --process [PID] as traces will eventually (in some cases quite soon) disappear from Console.app

Hi @stevemartina-salesforce @joeberlin123 @mfn @kungpaogao @kingfisher77! Sorry to bother you guys again, but I would like to know if the issue is still happening on your machines? It still never happens on mine, so I need help to investigate it, if it still occurs.

If the issue is gone for everyone, then I'll happily close this ticket of course!

@lwouis yes, it does. It just happened yesterday night but often times when I'm in "work mode" and can't just stop :-/

Last night behaviour was like it just stopped being recognized and after some time (minutes? 10-15?) it just worked again. I did not restart AltTab in this case but I remember from the past times I tried this, it didn't solve it.

I don't remember in which issue I read it, but something when windows don't respond, AltTab doesn't work. Though AFAIR you fixed that…

I'm on the latest version btw, 4.1.5

Could you please run this custom build with logs, and share the logs from Console.app when the issue happens? Without logs, I can't investigate further, and fix the issue unfortunately.

Roger!

and share the logs from Console.app

How does this work?

Open "Console" and filter for "alttab" in the search field and then… is there a way to export/save? Sorry not familiar with this app; this is all I see:
image

Funnily the "save" on the right side seems to only save the "filter", not the log.

... the described behaviour unfortunately still exists.

I had used the custom build. Unfortunately I was so stupid and installed updates via the GUI afterwards 🙈. So I have no log now...

But I noticed an interesting thing. I use https://www.deepl.com. The shortcut cmd+c defined there always seems to NOT work at the same time, when the shortcut for Alttab does not work. At some point, the shortcut starts to work again, Alttab also works again. Maybe this helps.

@mfn you can select the line like clicking with the mouse, or doing command-a to select all for instance, then when you hit the copy-paste shortcuts, it will copy-paste the text from all the lines. That's the easiest way to share all the alt-tab logs here

@joeberlin123 that's very interesting! If DeepL also stops responding to global shortcuts when AltTab does, it seems to indicate that the issue is not in AltTab code, but with your system. @mfn Could you try installing the DeepL mac app as well? It's small, and you hit command-c twice to trigger it, after selecting text anywhere. Next time AltTab stops working, you can try hitting that other shortcut, and seeing if it also fails on your machine like @joeberlin123. That would be a very interesting data point!

@lwouis I downloaded and took a look inside the DeepL app (DeepL Helper to be specific). It's written in Swift and disassembly is quite cryptic, I was only able to deduce that it uses the CGEventCreateKeyboardEvent and CGEventPost functions to inject ⌘C / ⌘V.

@Kentzo I would imagine that they use this to resend the shortcut after they have intercepted it? Not sure why they don't simply return the original event. Do you know if they use CGEventTapCreate to listen to shortcuts like AltTab?

I didn't find any uses of CGEventTapCreate.

If the issue is gone for everyone, then I'll happily close this ticket of course!

I haven't been running into any issues for a while now. For reference, I'm on macOS 10.15.5, latest AltTab, and not really running anything else related to keyboard shortcuts. Thanks for the hard work!

Hi, I'm having the same issue (alt+tab triggers mac switcher, icon still in tray, manually clicking shows switcher but doesn't fix problem). I tried updating from 4.0.0 to 4.2.0 and it didn't fix the problem. I also tried installing DeepL and can confirm cmd+c,cmd+c does not work there either. I'm going to try rebooting and see if that helps.

I'm on macOS 10.15.5.

Edit: Restarting fixed it for me

Hi, I'm having the same issue (alt+tab triggers mac switcher, icon still in tray, manually clicking shows switcher but doesn't fix problem). I tried updating from 4.0.0 to 4.2.0 and it didn't fix the problem. I also tried installing DeepL and can confirm cmd+c,cmd+c does not work there either. I'm going to try rebooting and see if that helps.

Additional info: Other apps with global shortcuts like Alfred work - even if AltTab and DeepL do not work. Are there possibly different variants to listen to global shortcuts?

Yes there are multiple APIs to listen to global shortcuts. I think 3:

  • The "modern" one AltTab uses
  • The old Carbon API
  • The very low level inputs API (to deal with a controller for example)

It is possible that the API used by AltTab has the issue, and not other APIs. That being said, there is no easy way to migrate to another API:

  • the old Carbon API doesn't support modifying events. We use this for AltTab so that if you are on a window and hit alt+tab, it blocks sending the tab key to the window, in addition to bringing AltTab UI up.
  • the low level inputs API is... low level, so we would need to handle different keyboard manually instead of having the OS abstract this for us. I don't want to handle Chinese/German keyboards manually in the app 😅

I filmed a video where I explain the overall situation with keyboard events on macOS. I share all my knowledge on the topics, highlight issues specific to Catalina, investigate the origin of the bug happening in this ticket, etc.

Please have a look at it, and share feedback if you have some 👍

@Kentzo @koekeishiya I think you guys may find this overview interesting!

Links mentioned in the video:

I don’t have time to go into details, but you could likely use the same set of APIs as the Dock uses to listen for cmd+tab; CGSRegisterKeyForConnetion/CGSStealKey.. etc. IIRC.

One final thought; the reason why this happens is likely because Secure Keyboard Input is enabled by some running application such as a password manager, focusing a nssecuretextfield or similar, and it is not propely disabled again by said app. This is a security mechanism of macOS built into the Quartz Event Tap API.

Omg @koekeishiya you're brilliant! I should have thought about this explanation as I investigated this issue in the past!

I just tested it, and indeed, on a system password field (I went to System Preferences > Security & Privacy, and clicked the lock icon at the bottom left to test it easily), AltTab and DeepL are indeed not capturing the keyboard shortcuts, whereas Alfred is!

This explains everything, and why it's never happening on my computer!

Now moving forwards has issues:

We could go the Alfred route, and use an API that ignores secure field. I imagine they use the Carbon API? But then how are they able to absorb the keys from the shortcut? Not sure. But anyway, there is a moral objection to that. I know that's it's Apple faults here, and that the Carbon API should be updated to also not receive keyboard inputs when password field are focused, but I still find it wrong to circumvent this protection by using the Carbon API.

That being said, if it's up to each app (I thought it was automatic from using specific NSView objects) to release this secure keyboard input, then we can have these apps break AltTab from their bad programming. It's quite a crazy situation that an app may not release some secure mode, and break many other apps on the system...

Not sure if we should:

  • Accept the current situation as the least bad
  • Move to Carbon API which means we could be a security vector to attack people's passwords (like Alfred is). Also that API has limitations like it seems it can't handle modifiers-only shortcuts
  • Other clever way to deal with this?

BetterTouchTool, which is one of the most sophisticated app in that space, seems to switch to the Carbon API, by default, when Secure Input is activated by an app:

image

I don’t have time to go into details, but you could likely use the same set of APIs as the Dock uses to listen for cmd+tab; CGSRegisterKeyForConnetion/CGSStealKey.. etc. IIRC.

I couldn't find these APIs, but looking at symbols from the SDKs, I think you may have meant these APIs?

_CPSRegisterForKey / _CPSRegisterForKeyOnConnection
_CPSStealKeyFocus / _CPSStealKeyFocusOnConnection

In any case, I think if we are willing to read password fields, we can simply use the public Carbon API to do so. At least it's commonly used. I couldn't find a single project on github using the above APIs 😅

@stevemartina-salesforce @joeberlin123 @mfn @kungpaogao @kingfisher77 next time you run into the issue, could you please type this in the Terminal?

ioreg -l -w 0 | grep SecureInput | awk 'BEGIN {FS="[^a-zA-Z0-9]+"} {print $8}' | uniq | xargs -n 1 ps aux

It should show you which app is activating Secure Input, thus preventing AltTab and other global-shortcut apps to work. This person explains that its their company's VPN that activates it as long as it's open. Pretty bad situation.

These scenarios make me swing towards moving to Carbon API...

Omg. This is such an incredible revelation!

I yet have to collect evidence from when it unexpectedly happens, but I was eager to try this out and can confirm this:

  • I opened 1Password
  • focus the password field
  • AltTab did not work ❗
  • the terminal output did show 1Password 👀

image

Now, not likely to AltTab away from that input _but_ the same applies when I edit a 1Password entry (which shows password fields covered, without having focus on the specific password field). And I would say it's not unlikely to edit 1password but then switch forth/back between other apps during this.

I'll make sure to run until false; do ioreg -l -w 0 | grep SecureInput | awk 'BEGIN {FS="[^a-zA-Z0-9]+"} {print $8}' | uniq | xargs -n 1 ps aux; sleep 1; done in a background terminal do capture the real offenders when it happens the next time outside lab conditions :)

Apple really dropped the ball on this system. It is a clear necessity to have a similar mechanism in an OS, but their UX is not good. They could for example have some UI indicator somewhere showing you that Secure Input is activated. Maybe in the menubar like they do for Location, maybe a dedicated popover. Anything showing the user that an app has activated this global flag, and that all accessibility software using the keyboard is now unable to function.

Another approach, I think better, would be to simply remove this global flag API, and rely on using NSSecureTextField which has that flag switching internalized. This way you guarantee no app forgets to turn it off, and for the user there is no need to communicate further as they can understand that password fields are protected.

But again, what's even the point of such feature if they forgot to check that flag when using their Carbon API, and you can still keylog using it? Apple what are you doing...

I have actually managed to tap into key events that also bypass Secure Keyboard Input, and it does not require any entitlements or elevated permissions at all (not even accessibility access or whatever it is that cgeventtap used.)

With this method I actually have access to more information than what is provided through Quartz events as well.

I’m sure there are other people out there that are aware of this, but I am not so sure if I should open source this.

TLDR; Input in macOS is extremely insecure and so called Secure Keyboard Input is a complete joke.

Edit: Turns out it does need access to the accessibility API; I had a shell session running that was already authorized.

@koekeishiya do you mean something like this? To bypass user-land security measures, you would need to run that as root though. Is your method working without root? Is it a low-level IOKit style method?

Currently here are the options I'm envisioning for AltTab being blocked when Secure Input is enabled by another app silently:

  • Display some UI to the user to communicate that AltTab is disabled as long as Secure Input is enabled. That strikes me as a good compromise, doesn't require a change of code for shortcut handling which is great currently
  • Switch to Carbon API, but it doesn't support modifier-only shortcuts, so I'm experimenting with private APIs: CGSSetHotModifierWithExclusion and CGSSetHotKeyWithExclusion. I have just managed to get it to work locally! This solution would handle all cases, but I'm a bit worried to migrate to this as there is a lot of low-level private API code involved. I'm basing my work off this great article

Do you think your technique would be a good approach for AltTab, or should I pick one of those options above?

Works without root and I am not using IOKit

Sent from my iPhone

On 16 Jul 2020, at 15:22, lwouis notifications@github.com wrote:



@koekeishiyahttps://github.com/koekeishiya do you mean something like thishttps://code.google.com/archive/p/logkext/? To bypass user-land security measures, you would need to run that as root though. Is your method working without root? Is it a low-level IOKit style method?

Currently here are the options I'm envisioning for AltTab being blocked when Secure Input is enabled by another app silently:

  • Display some UI to the user to communicate that AltTab is disabled as long as Secure Input is enabled. That strikes me as a good compromise, doesn't require a change of code for shortcut handling which is great currently
  • Switch to Carbon API, but it doesn't support modifier-only shortcuts, so I'm experimenting with private APIs: CGSSetHotModifierWithExclusion and CGSSetHotKeyWithExclusion. I have just managed to get it to work locally! This solution would handle all cases, but I'm a bit worried to migrate to this as there is a lot of low-level private API code involved. I'm basing my work off this great articlehttps://medium.com/@avaidyam/building-a-better-registereventhotkey-900afd68f11f

Do you think your technique would be a good approach for AltTab, or should I pick one of those options above?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-659407772, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPDZV5GLAU2ZIYDCU7QQ2TR335IRANCNFSM4KS6U36Q.

Regarding what’s best for alt-tab, I would go with the private APIs used by the Carbon hotkey framework (the ones you mentioned above) if they are able to give you the functionality you require.

I was in the process of writing a tool similar to skhd and wanted it to not get blocked by
Secure Keyboard Input this time around, and so I will probably finish that using the technique I discovered before I publish anything.

Sent from my iPhone

On 16 Jul 2020, at 15:35, Åsmund Vikane aasvi93@hotmail.com wrote:

 Works without root and I am not using IOKit

Sent from my iPhone

On 16 Jul 2020, at 15:22, lwouis notifications@github.com wrote:



@koekeishiyahttps://github.com/koekeishiya do you mean something like thishttps://code.google.com/archive/p/logkext/? To bypass user-land security measures, you would need to run that as root though. Is your method working without root? Is it a low-level IOKit style method?

Currently here are the options I'm envisioning for AltTab being blocked when Secure Input is enabled by another app silently:

  • Display some UI to the user to communicate that AltTab is disabled as long as Secure Input is enabled. That strikes me as a good compromise, doesn't require a change of code for shortcut handling which is great currently
  • Switch to Carbon API, but it doesn't support modifier-only shortcuts, so I'm experimenting with private APIs: CGSSetHotModifierWithExclusion and CGSSetHotKeyWithExclusion. I have just managed to get it to work locally! This solution would handle all cases, but I'm a bit worried to migrate to this as there is a lot of low-level private API code involved. I'm basing my work off this great articlehttps://medium.com/@avaidyam/building-a-better-registereventhotkey-900afd68f11f

Do you think your technique would be a good approach for AltTab, or should I pick one of those options above?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/lwouis/alt-tab-macos/issues/157#issuecomment-659407772, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABPDZV5GLAU2ZIYDCU7QQ2TR335IRANCNFSM4KS6U36Q.

to add another example of a window/app switching app handling secure input Contexts (at the time of this writing their site is down for maintenance, I assume this is only temporary 🤷 ) puts a little error sign in the menu bar with helpful text when clicked on:

image

I will probably finish that using the technique I discovered before I publish anything.

You got me so curious now! I can't wait to see how this works!

@nathanshelly oh that's nice! Even listing which app may be responsible.

That being said, if you look at the experience of Alfred, it just works. You can be editing a password, hit the shortcut, and Alfred shows up. They also handle shortcuts and modifiers-only shortcuts, indicating that they are not using either Carbon or Quartz API. I tried to retro-engineer their app but couldn't find which API they use.

Given that security is not the topic here since Secure Input is easy to defeat, I think I would rather go in the direction of best UX, whichever tech is behind it. AltTab is already way too low-level to go in the Mac AppStore anyway, so why not double down on tricks to get the best UX

I mean, this thing with the secure input… have your cursor in a firefox webpage password field and AltTab doesn't respond until you leave it (you'll get the default window manager though). Oh my

Just wanted to say thanks for the quick reply, @lwouis!

My issue with the Outlook desktop stopped after I quit Outlook and opened it again. Now it works fine so I cannot reproduce it. I use alt-tab as my shortcut by the way.

@koekeishiya Here are the results of my efforts so far:

| API | supports modifiers-only shortcuts | event propagation | works through Secure Input |
|---|---|---|---|
| CGEvent.tapCreate | Yes | Can propagate or not | No |
| RegisterEventHotKey | No | Can't propagate | Yes |
| NSEvent.addGlobalMonitorForEvents | Yes | Can't propagate | ? |
| CGSSetHotModifierWithExclusion + CGSSetHotKeyWithExclusion | Yes | Can't propagate | Yes |
| IOHID | Yes | ? | No |

Each of these 5 API fails to deliver a feature I need. I feel at a dead-end. Could you please consider sharing your new technique? You mentioned you will open-source it at some point. If you do it now, I would be able to integrate it into AltTab and have all users finally enjoy a flawless shortcut experience.

@lwouis It's not really robust enough for use in real software; I haven't spent more time trying to resolve the issue yet. I'll send you an email with what I have for now and you can feel free to experiment with it if you'd like.

Right now AltTab (and HyperSwitch as well!) refuse to listen to CMD-Tab. Totally. Even a restart does nothing (both apps).

Console:

default 22:54:59.554894+0200    tccd    -[TCCDAccessIdentity staticCode]: static code for: identifier com.lwouis.alt-tab-macos, type: 0: 0x7f9cf74195d0 at /Users/neo/Applications/AltTab.app
default 22:55:10.882852+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:10.882900+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:10.882937+0200    AltTab  keyboardHandler3: false, false
default 22:55:10.883003+0200    AltTab  keyboardHandler6: true
default 22:55:12.226674+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:12.226713+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:12.226777+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:12.226794+0200    AltTab  actionHandler2: false
default 22:55:12.226814+0200    AltTab  keyboardHandler3: false, false
default 22:55:12.226850+0200    AltTab  keyboardHandler6: true
default 22:55:12.316960+0200    AltTab  keyboardHandler1: true, 12, 0
default 22:55:12.317004+0200    AltTab  keyboardHandler2: 0, 0
default 22:55:12.317032+0200    AltTab  #Error Unexpected key code 0 for the FlagsChanged event
default 22:55:12.317049+0200    AltTab  keyboardHandler3: false, false
default 22:55:12.317087+0200    AltTab  keyboardHandler6: true
default 22:55:22.883115+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:22.883171+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:22.883212+0200    AltTab  keyboardHandler3: false, false
default 22:55:22.883263+0200    AltTab  keyboardHandler6: true
default 22:55:24.090773+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:24.090816+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:24.090888+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:24.090908+0200    AltTab  actionHandler2: false
default 22:55:24.090928+0200    AltTab  keyboardHandler3: false, false
default 22:55:24.090969+0200    AltTab  keyboardHandler6: true
default 22:55:27.714647+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:27.714684+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:27.714715+0200    AltTab  keyboardHandler3: false, false
default 22:55:27.714759+0200    AltTab  keyboardHandler6: true
default 22:55:28.370693+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:28.370734+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:28.370801+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:28.370820+0200    AltTab  actionHandler2: false
default 22:55:28.370837+0200    AltTab  keyboardHandler3: false, false
default 22:55:28.370883+0200    AltTab  keyboardHandler6: true
default 22:55:33.275563+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:33.275625+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:33.275665+0200    AltTab  keyboardHandler3: false, false
default 22:55:33.275716+0200    AltTab  keyboardHandler6: true
default 22:55:34.051395+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:34.051455+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:34.051522+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:34.051537+0200    AltTab  actionHandler2: false
default 22:55:34.051554+0200    AltTab  keyboardHandler3: false, false
default 22:55:34.051604+0200    AltTab  keyboardHandler6: true
default 22:55:34.914887+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:34.914930+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:34.914962+0200    AltTab  keyboardHandler3: false, false
default 22:55:34.915015+0200    AltTab  keyboardHandler6: true
default 22:55:35.034754+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:35.034792+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:35.034857+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:35.034872+0200    AltTab  actionHandler2: false
default 22:55:35.034888+0200    AltTab  keyboardHandler3: false, false
default 22:55:35.034926+0200    AltTab  keyboardHandler6: true
default 22:55:43.740091+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:43.740196+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:43.740288+0200    AltTab  keyboardHandler3: false, false
default 22:55:43.740439+0200    AltTab  keyboardHandler6: true
default 22:55:43.891484+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:43.891558+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:43.891710+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:43.891830+0200    AltTab  actionHandler2: false
default 22:55:43.891895+0200    AltTab  keyboardHandler3: false, false
default 22:55:43.891995+0200    AltTab  keyboardHandler6: true
default 22:55:45.787810+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:45.787861+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:45.787899+0200    AltTab  keyboardHandler3: false, false
default 22:55:45.787950+0200    AltTab  keyboardHandler6: true
default 22:55:46.083280+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:46.083328+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:46.083472+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:46.083513+0200    AltTab  actionHandler2: false
default 22:55:46.083561+0200    AltTab  keyboardHandler3: false, false
default 22:55:46.083616+0200    AltTab  keyboardHandler6: true
default 22:55:50.019309+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:55:50.019347+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:55:50.019376+0200    AltTab  keyboardHandler3: false, false
default 22:55:50.019424+0200    AltTab  keyboardHandler6: true
default 22:55:50.891154+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:55:50.891196+0200    AltTab  keyboardHandler2: 256, 55
default 22:55:50.891261+0200    AltTab  actionHandler1: holdShortcut, false
default 22:55:50.891278+0200    AltTab  actionHandler2: false
default 22:55:50.891294+0200    AltTab  keyboardHandler3: false, false
default 22:55:50.891336+0200    AltTab  keyboardHandler6: true
default 22:56:07.531908+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:56:07.531958+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:56:07.531992+0200    AltTab  keyboardHandler3: false, false
default 22:56:07.532046+0200    AltTab  keyboardHandler6: true
default 22:56:08.812453+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:56:08.812491+0200    AltTab  keyboardHandler2: 256, 55
default 22:56:08.812555+0200    AltTab  actionHandler1: holdShortcut, false
default 22:56:08.812571+0200    AltTab  actionHandler2: false
default 22:56:08.812587+0200    AltTab  keyboardHandler3: false, false
default 22:56:08.812645+0200    AltTab  keyboardHandler6: true
default 22:56:09.065196+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:56:09.065241+0200    AltTab  keyboardHandler2: 256, 0
default 22:56:09.065268+0200    AltTab  #Error Unexpected key code 0 for the FlagsChanged event
default 22:56:09.065288+0200    AltTab  keyboardHandler3: false, false
default 22:56:09.065402+0200    AltTab  keyboardHandler6: true
default 22:56:10.019712+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:56:10.019753+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:56:10.019784+0200    AltTab  keyboardHandler3: false, false
default 22:56:10.019824+0200    AltTab  keyboardHandler6: true
default 22:56:10.411879+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:56:10.411916+0200    AltTab  keyboardHandler2: 256, 55
default 22:56:10.411978+0200    AltTab  actionHandler1: holdShortcut, false
default 22:56:10.411993+0200    AltTab  actionHandler2: false
default 22:56:10.412009+0200    AltTab  keyboardHandler3: false, false
default 22:56:10.412049+0200    AltTab  keyboardHandler6: true
default 22:56:10.666240+0200    AltTab  keyboardHandler1: true, 12, 0
default 22:56:10.666296+0200    AltTab  keyboardHandler2: 0, 0
default 22:56:10.666328+0200    AltTab  #Error Unexpected key code 0 for the FlagsChanged event
default 22:56:10.666351+0200    AltTab  keyboardHandler3: false, false
default 22:56:10.666748+0200    AltTab  keyboardHandler6: true
default 22:56:13.804382+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:56:13.804438+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:56:13.804478+0200    AltTab  keyboardHandler3: false, false
default 22:56:13.804527+0200    AltTab  keyboardHandler6: true
default 22:56:15.228121+0200    AltTab  keyboardHandler1: true, 12, 256
default 22:56:15.228173+0200    AltTab  keyboardHandler2: 256, 55
default 22:56:15.228257+0200    AltTab  actionHandler1: holdShortcut, false
default 22:56:15.228281+0200    AltTab  actionHandler2: false
default 22:56:15.228303+0200    AltTab  keyboardHandler3: false, false
default 22:56:15.228352+0200    AltTab  keyboardHandler6: true
default 22:56:16.692225+0200    AltTab  keyboardHandler1: true, 12, 1048840
default 22:56:16.692266+0200    AltTab  keyboardHandler2: 1048840, 55
default 22:56:16.692298+0200    AltTab  keyboardHandler3: false, false
default 22:56:16.692380+0200    AltTab  keyboardHandler6: true

SecureInput grep check:

~ $ until false; do ioreg -l -w 0 | grep SecureInput | awk 'BEGIN {FS="[^a-zA-Z0-9]+"} {print $8}' | uniq | xargs -n 1 ps aux; sleep 1; done
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701832 142584   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreSe
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701832 142584   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701832 142584   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701832 142584   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
USER   PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
neo    181   0.0  0.2  6701308 142576   ??  Ss   Sun05PM   0:10.35 /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console

FTR I'm running an unversioned (?) version you provided at some point via direct ZIP, sorry don't remember from where exactly, was a few weeks though now:
image

Right now AltTab (and HyperSwitch as well!) refuse to listen to CMD-Tab. Totally. Even a restart does nothing (both apps).

That's an Apple thing. I've tried quite a few cmd-tab/alt-tab style apps to replace the standard osx cmd-tab ui and none of them will work with cmd-tab. It seems like Apple has that hard coded in the firmware, or something, so that you cannot overwrite it.

🤔

It works all the time, it just stopped in the middle "right now".

Probably need to restart the machine but don't want to right now 😄

@reifnotreef there is no issue using cmd-tab. Try it out for yourself. Go in AltTab's preferences, and set cmd-tab to any shortcut. It will work.

@mfn so it's clearly Secure Input. If Secure Input is enabled, AltTab can't read any keyboard input. You have /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console enabling Secure Input and locking you out of AltTab.

I spent a few hours online looking for explanations, and it seems to be a known macOS bug. After login in your session, this loginwindow console process doesn't disable SecureInput. It should, but it doesn't. People have said that locking the screen, and re-entering password have worked for some of them. Others have had to logout and back login back in the session

I can only advise that you upgrade your macOS version in hope that Apple fixed that bug. What version are you on, at the moment?

Also thanks a lot for your diligence in running the test version I shared with you. Please feel free to update to the latest now. It contains numerous improvements and new features.

Finally, know that I'm working on a way to have AltTab work even when SecureInput is enabled. It's not supposed to be possible, but it may just be, thanks to Apple quality control. I'll keep everyone posted in this ticket if I make progress.

What version are you on, at the moment?

To the best of my knowledge, I'm on the latest: 10.15.6 (19G73)

Please feel free to update to the latest now

Thanks, done. Wohoo, dark mode icon 😄


I guess it was too late, I didn't realize this was the SecureInput issue despite running the very command; apologies. I guess I was too tired. In my mind I related …loginwindow console to the console.app I was having open 🤷‍♀️

@reifnotreef there is no issue using cmd-tab. Try it out for yourself. Go in AltTab's preferences, and set cmd-tab to any shortcut. It will work.

I have tried several times, with several different apps, and nothing will register the shortcut when assigned. Is there something in OSXs settings I need to change? It's extremely frustrating having different shortcuts between OS's.

@reifnotreef hard to know what's wrong with your setup without more information. Are you using an external keyboard? Software like Karabiner, Synergy, anything that impacts the keyboard? Could you please see the information in this thread? It may be a similar scenario you're having, where other stuff gets in the way. AltTab itself supports binding to any shortcut. The only exception I know of is if a shortcut is already registered in System Preferences > Keyboard > Shortcuts, which is not the case for cmd+tab. Anyway, many people use AltTab with cmd+tab, so it is indeed possible

To anyone interested

I've been working on a branch where I rewrote the keyboard handling using another API. It has different pros and cons compared to the current implementation:

Pros:

  • Not affected by Secure Input. It works on password fields, or if some app doesn't turn Secure Input off.

Cons:

  • ~Can't override cmd+tab. I guess it has lower priority than the previous method.~ Update: I found a solution with new private APIs. It's working during my local tests.
  • Doesn't work on another thread like the old method can, so things like quick switches are not possible since the UI will not know you released the shortcut until it has displayed the thumbnails view already. So flashing occurs. Here there are probably (heavy) ways to handle that, like having the keyboard monitoring happen on another dedicated process, and exchange through XPC. Exploring XPC could be a gateway to #371 as a side-effect.

I'm not sure what to do now. Should I release this? Maybe I should work on the cons, and figure out some breakthroughs? This stuff is a nightmare to work on btw 🙉

If you're interested, please try out this build and let me know if it works for you. Try it under Secure Input and try it with command+tab. Also be tricky and try all shorts of messy things like modifiers-only shortcuts, etc.

If you're interested, please try out this build and let me know if it works for you. Try it under Secure Input and try it with command+tab. Also be tricky and try all shorts of messy things like modifiers-only shortcuts, etc.

Working with this build the whole day without any problems so far. Usually AltTab stopped working because Secure Input quite soon. I'm using it with command+tab.

2 things I use are not working well in this version:

  • Fast switching with apparition delay of 100ms (had to set to 0ms and get a glitch)
  • The use of Cmd+Shift+Tab to select previous window is bringing the default MacOS switcher in front of AltTab.

Fast switching with apparition delay of 100ms (had to set to 0ms and get a glitch)

~What do you mean? I don't get it. Maybe share a video to help visualize the issue?~

Edit: I was able to reproduce! This is another consequence of keyboard input being back on the main thread. That's unfortunate. I'll see if I can mitigate this

The use of Cmd+Shift+Tab to select previous window is bringing the default MacOS switcher in front of AltTab.

~Oh! I'll look into that. I'm using a private API to specifically disable the native switcher if the user sets the main shortcut to cmd-tab. I forgot about the shift shortcut!~

Edit: Ok I fixed that issue

Here is a new build where I fixed both issues. I'll be on vacations for 9 days. Please everyone who can, take that time to test this build: AltTab.app.zip

The code is a mess, and I need to reorganize this so it's more approachable, but from my tests, it's looking good. The complexity of keyboard shortcuts being so customizable and combinations of preferences make it really hard to be confident though. That's why I need help with QA 👍

Tested here and both fixes are OK, thanks!
Found a new one: on the old version we can just hold Cmd+Tab pressed to cycle fast between windows thumbnails. Now holding the keys simply does nothing (seems like the "repeat" behavior of holding a key is disabled).

Another one: when Alt+Tabbing the AltTab Preferences window is not showing itself in the list.

OK, I'll start using this test build from now until whenever to see if the problem remains or not!

I've also noticed that the AltTab preferences window does not show up in the switcher when using the test version.

Another change: with this version, Cmd-Shift-Tab no longer pops up the regular macOS application switcher as before (I had been using this as a workaround when I wanted to switch by apps).

Here is a new build where I fixed both issues. I'll be on vacations for 9 days. Please everyone who can, take that time to test this build: AltTab.app.zip

The code is a mess, and I need to reorganize this so it's more approachable, but from my tests, it's looking good. The complexity of keyboard shortcuts being so customizable and combinations of preferences make it really hard to be confident though. That's why I need help with QA 👍

Should we continue testing, or go back to main build? I'm still on this test build and seems to fix it, because I've forgotten about the bug completely. :)

@mindfulsource I waited a bit, then as everyone reported good results, I merged the PR and closed this ticket. You can go back to the main/public release now

Was this page helpful?
0 / 5 - 0 ratings