I tried installing this on a local device. I didn't get the unsigned binary prompt. Is the new binary now signed correctly?

Also, something very odd is going on if the user can't click on items in System Preferences. I'm not aware of code in Chrome that intercepts mouse events to *other* applications. If we can get a local repro, we'd be able to better chase down the issue.

Is this a reproducible problem for you? [e.g. the button is unclickable if and only if chrome is running?]

I've installed plenty of other unsigned applications with chrome running and haven't had this issue.

I also tried with some coworkers, but couldn't repro. It definitely seems to be a common enough issue, but likely there are additional preconditions to it manifesting. I posted on the app's google group (https://groups.google.com/forum/#!topic/osx-karabiner/3aewXjXmuJM), so hopefully someone from there can suggest better repro steps.

It isn't actually *possible*, as far as I know, to intercept mouse clicks directed to other apps in a way that prevents them from getting delivered. If Chrome is somehow causing that to happen it sounds like a major macOS bug (?), although obviously if we can avoid doing it on our side we should.

I'm going to mark this Unconfirmed instead of Untriaged and Needs-Feedback pending working repro steps.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Mac triage: this is still Needs-Feedback; we're waiting for a working repro.

Did we find a working repro? If not, I'll close in the next sweep and we can reopen when a consistent repro is found.

I've pinged the gibhub repro issue tracker (https://github.com/tekezo/Karabiner-Elements/issues/1415), so if possible I think it'd be nice to wait a few days in case anyone monitoring the bug queue there has info on reliable repro steps. If not, then I agree this can be closed as not reproable.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tested the issue on chrome reported version 66.0.3359.170 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://pqrs.org/osx/karabiner/
2) Clicked on "Download Karabiner-Elements-12.0.0", Karabiner-Elements got downloaded
3) Installed Karabiner-Elements, able to install properly and access it

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it.

Thanks!

Deleted: 842813.mp4 1.4 MB

	842813.mp4 1.4 MB View Download

Re. #10, that didn't include allowing the kext in System Preferences.

From what I can tell, System Preferences checks that the event source PID is either its own or '0'. Issues can come up when an app uses an event tap to intercept events, which many of the apps in the linked list do. Unfortunately, I haven't managed to get Chrome into a state where it intercepts events like this. If you or the developer of Karabiner have a set of repro steps for Chrome, we should look into this.

- - -

FWIW, here's some Swift code that can be pasted into a playground which should mimic the check done by that button. Open the companion editor and then click the red square which appears there. The "source" value should either be zero or match the "pid" value. If it's something else, then a process is intercepting events. You can use this to figure out whether Chrome is in a state where it would prevent the "Allow" button from being clicked:

    import Cocoa
    import PlaygroundSupport

    class EventSourceView: NSView {
      override func mouseDown(with event: NSEvent) {
        let cgEvent = event.cgEvent!
        print("source: \(cgEvent.getIntegerValueField(.eventSourceUnixProcessID)), target: \(cgEvent.getIntegerValueField(.eventTargetUnixProcessID)), pid: \(getpid())")
        super.mouseDown(with: event)
      }
    }

    let view = EventSourceView(frame: NSRect(x: 0, y: 0, width: 100, height: 100))
    view.wantsLayer = true
    view.layer!.backgroundColor = NSColor.red.cgColor
    PlaygroundPage.current.liveView = view

This bug is currently restricted because it was filed by a Googler and has an attachment, but I'm going to make it public unless anyone has a reason not to.

Oh, finally, here's a video of me failing to repro the issue.

Deleted: chrome_karabiner_exception.mp4 788 KB

	chrome_karabiner_exception.mp4 788 KB View Download

Based off of #13, marking this issue as WontFix. If there is an alternate repro, feel free to reopen.

I was able to reproduce this (using the playground from #11) with an old version of the Google Play Music app (https://chrome.google.com/webstore/detail/google-play-music/fahmaaghhglfmonjliepjlchgpgfmobi). With that app installed in Chrome the red button returns the PID of the main Chrome browser process as the source; as soon as I remove the app from Chrome the source returns 0.

bizarre!

Over to sdy@.

For what it's worth, I also ran into this bug, I had the same Play Music extension installed and I was unable to authorize Logitech Control Center (https://support.logitech.com/en_us/software/logitech-control-center-for-macintosh-os-x) while Chrome was running.

**UI Mass Triage**
Adding labels for expert review.