-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
It's work fine on Mojave,but stop working everytime when I reboot the system. #44
Comments
It's happening for me too. I installed with homebrew. |
After installing it and running it adds an entry to auto start, however, restarting the device makes the app to break - as running it again prompts us with a "do you wish to autorun" screen once more |
Issues acknowledged. I am still working on upgrading the app internals to use non-deprecated APIs. |
It stops working also after hibernation, not only a reboot :( |
Have you codesigned SlowQuitApps, and have you added it to the Accessibility list in System Preferences > Security & Privacy > Privacy? Mojave's TCC doesn't seem to behave well with unsigned processes, and maybe that breaks SlowQuitApps at login and wake-from-safesleep. I noticed this with my own AppleScript apps, i.e. they were asking for accessibility permissions again and again, and once I codesigned them, they worked fine. (You can use any self-issued code-signing certificate; an Apple Developer ID Applications certificiate is not needed. EDIT3: I'm actually using a self-issued certificate chain, complete with Root CA and intermediate certificate, following the Apple Developer ID naming scheme to the letter. /ENDOFEDIT Maybe ad-hoc signing also works, but I haven't tried that yet.) I've just tested shutting down my Mac, and rebooting, and SlowQuitApps v0.6.0 loads fine at login, and works as it should, although we still have the alert sound bug, so I'll have to revert to v0.5.0 nonetheless. (Mojave 10.14.1) EDIT1: just tested a second reboot (without shutdown), and SlowQuitApps loads fine at login & works properly, except for the alert sound bug. EDIT2: it sometimes also helps (after an update) to untick & retick the application in the Accessibility list; that's what I also did. |
The codesign system is quite frustrating and designed to extract (extort?) money first, and add security second. If Apple was serious about security, macOS devs should be able to get a Developer ID certificate for free or at a very reduced price. I don't want to pay for extra services (Mac and iOS App Store publishing) that I will not use. I suspect however, that I will be forced to pay the fee if a working solution cannot be found.
I don't think anyone is going to want to install a Root CA from a random dev on the internet to use an app. Especially when the app in question is a (benevolent) keylogger.
It doesn't when I tried it, but it could just be that I didn't tick the magic combination of compiler flags + Xcode buttons.
Start on login is pretty much in a weird half-broken state because the API that I was using to add SQA to system startup is pretty much deprecated/gone. The new way to do it involves registering a helper app whose job is to start the main app. |
Yes, that might have been what caused the latest problems with Firefox. I have a login script running anyway, so I've added EDIT: scrap that; SQA will ask to be put on the login items list every time, so the login script solution is a no-go.
Right. That's why it's better that the user creates his own certificate (chain) for these purposes, so there is no CA trust issue in the first place. As for code signing in general, I believe Apple should give every user a code-signing certificate, but one that is by default only trusted on the local machine. That would be fine for unsigned applications. Users just codesign them themselves with a little helper app provided by a third-party or even Apple, with required admin privileges (root) for protection against malware signing itself with the user's certificate, and then the app will run fine locally, but if they copy the app to another computer, it would need to be codesigned for that machine afresh. Just my 2¢. |
Update autostart integration - #44 Also make it more compatible with Mojave SDK.
Please give v0.7.0 a go, it might fix this issue... |
@dteoh the v0.7.0 update is working for me after initial install. I'll report back should I notice anything strange after a reboot but all OK so far. Thanks. |
Good luck. Not working for me. (Well, it's working, but it's spawning constant alert sounds.) |
@dteoh It works fairly well for me.
It works normally if I also release Cmd, and then press Cmd-Q.
One confusing thing, perhaps due to Homebrew Cask, was that the app wanted Accessibility permissions again after being updated. But in Accessibility, it was already there. I just pressed the |
It's not crashing, but I noticed a new issue where after quitting an app with Cmd-Q, I can't close the Cmd-Tab menu with the Esc key anymore. I have to click out of it with the mouse. |
Will be fixed as part of #55. |
I can find it in Activity Monitor.app.
![image](https://user-images.githubusercontent.com/8327775/47702609-769c7d00-dc58-11e8-94de-06803117b080.png)
But it doesn't work anymore.
Cmd+Q also lose it's function.
And it's work when I quit it on Activity Monitor.app and restart.
The text was updated successfully, but these errors were encountered: