Unexpected behaviour in my app monitoring local events with cmd+alt+42 when Alfred running

[Flyshewoorst]

As a developer, I'm using Alfred myself a lot. While I was working on my own little private project, I've noticed a very strange behaviour when Alfred 3.8 is running. It unfortunately breaks my application by altering the key code of NSEvent/CGEvents of type keyDown and keyUp observed by a local event monitor.

I'm using a local event monitor and a global monitor with the .headInsertEventTap option to observe events of type .keyDown, .keyUp and .flagsChanged within my application. The two are used for completely different purposes and only one of them is active at a time. While the debug output of the global monitor always yields correct key codes, the local monitor does not under the following circumstances:

 

- The key with key code 42 is pressed (# on QWERTZ-keyboards)

- The modifier flags ALT and CMD are active

 

If the above conditions are met, the key code is changed to 8, which is C on QWERTZ-keyboards. Turning off Alfred prevents this from happening. I've made sure to disable all power pack workflows. Issue occurs in MacOs 10.14 - 10.14.3.

Edited February 22, 2019 by Flyshewoorst

[deanishe]

1 hour ago, Flyshewoorst said:

The key with key code 42 is pressed (# on QWERTZ-keyboards)

 

For the majority who have QUERTY keyboards, that's the backslash key.

 

1 hour ago, Flyshewoorst said:

changed to 8, which is C on QWERTZ-keyboards

 

Also C on a QWERTY.

Edited February 22, 2019 by deanishe

[Flyshewoorst]

Just to make sure: My point is that the key code of the locally observed event is changed from 42 to 8 when Alfred is running and the ALT and CMD modifiers are active, keyboard informations have been added for the sake of completeness. 

Edited February 22, 2019 by Flyshewoorst

[Andrew]

@Flyshewoorst The only event tap Alfred uses is for snippet auto-expansion, and this is a read only view over the events for observing key patterns matching snippet keyword strings. At no point does Alfred directly alter lower level events, so there is no way Alfred can be directly altering the events in the way you describe.

 

Could you provide a little more information on what you're experiencing (perhaps a step by step, as I can't see how to reproduce what you're trying to explain), and perhaps what you're trying to do yourself, as this may help point to why you are experiencing oddity. As you've seen in the global monitor, there isn't an issue, so it could be something to do with the way you're interacting with your local tap.

 

Also, do you have any other apps installed which may be causing events to be changed (even in relation to Alfred), such as Karabiner.

 

Andrew

[Flyshewoorst]

1 hour ago, Andrew said:

@Flyshewoorst The only event tap Alfred uses is for snippet auto-expansion, and this is a read only view over the events for observing key patterns matching snippet keyword strings. At no point does Alfred directly alter lower level events, so there is no way Alfred can be directly altering the events in the way you describe.

 

I get that you guys don't do it by intention (why would you?), but I definitely notice a change with Alfred running and without having it running.

 

Quote

  

Could you provide a little more information on what you're experiencing (perhaps a step by step, as I can't see how to reproduce what you're trying to explain)

 

Sure thing.

1: Create a new Cocoa project (I'm using Swift here, but shouldn't make a difference).

2: Replace the ViewController.swift's code with:

import Cocoa

class ViewController: NSViewController {

    override func viewDidLoad() {
    super.viewDidLoad()
    
        NSEvent.addLocalMonitorForEvents(matching: [.keyUp, .keyDown, .flagsChanged], handler: onKeyEvent)
    
    // Do any additional setup after loading the view.
    }
    
    private func onKeyEvent(_ event: NSEvent) -> NSEvent? {
        
        print(event.keyCode)
        return event
        
    }
    override var representedObject: Any? {
    didSet {
    // Update the view, if already loaded.
    }
    }
}

3: Observe console output when Alfred is running and when it is not running. Use CMD + ALT + \ (Key with keycode 42, to be precisely) to reproduce the issue.

 

I've made sure that it isn't BTTs fault, no other apps like Karabiner or Keyboard Maestro are installed.

Edited February 23, 2019 by Flyshewoorst

[deanishe]

Hmm. My system doesn't like the shortcut ⌥⌘\. It doesn't register at all.

 

Whether Alfred is running or not makes zero difference.

[Andrew]

I've been trying to reproduce this issue this morning, and other than 1Password assume the hotkey alt+cmd+keycode 42 which is cmd+alt+\ on my keyboard, I quit 1Password and I have not been able to reproduce the issue you describe.

 

Is there a specific reason you're using NSEvent.addLocalMonitorForEvents instead of using the Responder Chain which is the default and recommended way to interact with key events within your app?

 

I'm changing the title and moving this out of Alfred bugs.

[Flyshewoorst]

1 hour ago, Andrew said:

 

Is there a specific reason you're using NSEvent.addLocalMonitorForEvents instead of using the Responder Chain which is the default and recommended way to interact with key events within your app?

 

Yes, I need to record and display whole sequences of keys, including active modifiers. Could it be that only QWERTZ-Keyboards are affected?

By the way: It shouldn't matter if I'm using a local monitor or not. Alfred seems to break local monitors, and that shouldn't be the case.

 

Quote

I've been trying to reproduce this issue this morning

 

How? By following the steps I described?

 

Quote

moving this out of Alfred bugs.

 

Why? Alfred affects third party applications in a way that is not intended. How is this not a bug?

Edited February 25, 2019 by Flyshewoorst

[Andrew]

@Flyshewoorst yes, I added a QWERTYZ keyboard layout, created a new project in XCode adding a local monitoring for events in the way you described, and watched the events coming in. When typing cmd+alt+# on the QWERTYZ keyboard, I see keycode 42 coming through as expected when Alfred is or isn't running.

 

This mixed with the fact that Alfred doesn't alter macOS level events means there is nothing I can do to fix this.

 

Perhaps try temporarily creating a new user account and try your tests there. It could be that there is an underlying configuration or app on your profile which is inadvertently causing the unexpected behaviour. By trying this on a new user account, you'll get default behaviour.

 

Also, is your keyboard a standard macOS keyboard, or do you have a 3rd party keyboard?

[deanishe]

Turned off a conflicting shortcut in System Preferences, and @Flyshewoorst's program works exactly as it should on my machine: QWERTY or QWERTZ, I'm seeing 42.

[Flyshewoorst]

Hello,

 

I've bought a new Mac recently and I'm still getting this error without having configured any Shortcut within System Preferences (so everything is set to default, "ab Werk", as we are used to say in Germany).

Edited May 11, 2019 by Flyshewoorst

[deanishe]

2 hours ago, Flyshewoorst said:

so everything is set to default, "ab Werk", as we are used to say in Germany

 

So you haven't migrated any of your user settings or applications?

 

If you did, did you also try to replicate the issue using a clean and empty new user account?

[Flyshewoorst]

26 minutes ago, deanishe said:

 

So you haven't migrated any of your user settings or applications?

 

Nope, clean setup. Fewer applications than before.

Edited May 11, 2019 by Flyshewoorst