-
-
Notifications
You must be signed in to change notification settings - Fork 543
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
macOS - Continual "Control System Events" Message #380
Comments
Thanks for the detailed report. It shouldn't be necessary but if you can try to add Full Disk Access permissions for activitywatch that might fix this problem :/. If that fixed it there should be quite a nice fix for the next release. |
Hi thanks for the response! I adding Full Disk Access permissions and did a full restart but there was no change to the issue. I still got the pop up and the app is causing my computer to stutter. By stutter I mean that while continuously typing, moving the mouse or clicking on anything every few seconds it's like there are a few frames dropped. Everything freezes for a second then unfreezes |
@8bitgentleman Could you try disabling the server, window watcher, and afk watcher (separately) from the trayicon, and then see if you still get the messages and the stutter? |
@ErikBjare Disabling all of those from the tray icon stops the constant messages and stutter. By process of elimination I turned on and off several combinations of those modules and it seems that the window watcher is the one causing the issue |
That's really helpful to know, thanks! We'll look into it. |
I just tried this on a clean (latest Catalina so 10.15.3) virtual machine and can not reproduce. ActivityWatch asked me for the Automation - System events permissions and for the accessibility permissions, and after giving both it works fine. @8bitgentleman Can you confirm you installed it from the latest .dmg on the releases page https://github.com/ActivityWatch/activitywatch/releases/tag/v0.9.0 ? If you don't mind just trying to re-download and drag it to /Applications could help. You did have the right version tag (v0.9.dev+c815323). I will try to setup a Mojave virtual machine, but it will take a bit of time. Will also look into improving the logging and warning about invalid permissions to the user for the next release. |
@xylix Yes I used the newest .dmg from that release. To be sure I uninstalled and did a redownload from the link you provided however the same error occurred. Would the output from the macOS console be of any use? It captured several warnings and system events related to activitywatch |
If they are similar to these errors https://gist.github.com/xylix/5a85fde8f69f176402b524a16b9692fd they are related to ActivityWatch being self signed instead of signed with an Apple-approved developer key and/or to our signing processes weirdnesses. If it's something different it could be important though. Thanks for your patience and fast responses :). |
For now the only thing I think will actually completely fix this will be adding a new check for "Does the .app have all the necessary permissions?" at startup and prompting for the missing ones. Something like this https://i.stack.imgur.com/YKAyE.png . And better logging of missing permissions. I'll be working these into the next release but that might take anywhere from a few weeks to a month. @8bitgentleman Sorry but I can't really suggest any more workarounds for the .app. If you really want to get 0.9.0 working you could try running the newest macos .zip in the terminal, but that's kinda hard to autostart and rough around the edges. |
I think the problem is how we get the active window in the window watcher.
We use a compiled AppleScript that executes every second (or whatever
interval the window watcher checks in, I've forgotten).
It would be nice to instead do the same thing directly from the Python
process, and it just might fix the issue.
…On Sat, 21 Mar 2020, 09:48 Kerkko Pelttari, ***@***.***> wrote:
For now the only thing I think will actually completely fix this will be
adding a new check for "Does the .app have all the necessary permissions?"
at startup and prompting for the missing ones. Something like this
https://i.stack.imgur.com/YKAyE.png . And better logging of missing
permissions.
I'll be working these into the next release but that might take anywhere
from a few weeks to a month.
@8bitgentleman <https://github.com/8bitgentleman> Sorry but I can't
really suggest any more workarounds for the .app. If you really want to get
0.9.0 working you could try running the newest macos .zip in the terminal,
but that's kinda hard to autostart and rough around the edges.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#380 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKXDOVTVYLDONKR2DFEKGTRIR5PPANCNFSM4LPOA4GQ>
.
|
That would explain it. I'll take a look. It could be possible with pyobjc. |
@xylix this is the console log, there are some similar errors and some different ones I was hoping to use activity watch since I started working from home recently so thanks for looking into this guys! |
@ErikBjare @xylix Maybe revive this old PR then? ActivityWatch/aw-watcher-window#29 |
@8bitgentleman Do you still have the problem? / Did you switch to another software? If you're still interested in getting activitywatch working, one possible thing to try would be to remove and re-add the accessibility permissions for activitywatch.app. |
@xylix I am still very interested in using activitywatch and still have all of the problems described in the issue. I have tried removing and re-adding the accessibility permission (and even full disk access) but that had no effect on the constant pop-ups or the noticeable operating system lag/slowness. (The lag and slowness disappears if aw-watcher-window is disabled). |
Sad to hear that the workaround isn't helping. I'm still working on improving the reporting of macos permission issues in the app but it isn't quite complete yet. |
I'm also getting this error on MacOS 10.14.6 with ActivityWatch 0.9.2 installed via homebrew cask. Disabiling window watcher does stop stutter. |
Same issue on macOS 10.14.6, ActivityWatch version 0.9.2.
On top of that, it's still unable to determine window titles, except for systems preferences window. And on another note, maybe another issue though, not sure, ActivityWatch detects VSCode as "Electron" in top apps list. If I can provide further info, test some builds etc, please let me know. |
That's an vscode bug that it seems like they will never fix. |
@johan-bjareholt understood, sad indeed. |
I am sorry for spamming, but I'm trying to find out what's wrong. My finding is that if I unpack .zip from releases page - it actually works ok.
I decided to also check how it works from bundled app:
And again, works well. Since iTerm2 already has permission it doesn't even ask for one. No freezes. Window title detection works. Hope it helps. edit:formatting |
Thanks for good description of the workaround. I still haven't been able to reproduce the I'll be taking a better look on sunday, let me know if you come up with anything. |
Unfortunately, I can't help more as I don't have experience on macOS development whatsoever. Somehow it inherits it ok when manually run from iTerm2, but it asks for permission for iTerm2 when run this way, not for ActivityWatch. So 2 things come to mind:
I'm not sure if what I'm talking about makes sense, just throwing it out there. |
@8bitgentleman Yeah with @officerats Thanks for the guesses,
|
Thanks @xylix wow that's very bizarre, launching it with |
Removing high priority label as it only appears to happen on Mojave and there is a workaround. |
Of course, no one owes nothing to anyone here, but it's not the first time that it's noticeable that versions older than Catalina are neglected, just the wording "only on versions older than Catalina". In the meantime, lots of companies, including the one I work for - 20000 seats, and individual Mac owners are postponing upgrade to Catalina, because it's a buggy mess even few minor releases after, basically macOS Vista. Are you choosing the priority of the bugs based on factual info like telemetry from your user base or under assumption that everyone moves to lastest macOS ASAP? |
We don't assume that everyone will start using Catalina right now, but in the long run we expect the majority of our users to upgrade their operating system. As far as I understand the workaround is the same way the application worked a couple of months ago without the .app bundle. If someone finds a fix though that'd be great, but it's not as urgent as it still works. Maybe we should add a notice though that the .app is not recommended on macOS versions prior to Catalina? |
@officerats The priority is just a reflection of the priorities of core contributors (volunteers who work for free), we simply don't always have the will nor resources to fix hard and platform-version specific bugs like this (we don't even have a machine with pre-Catalina). It's a real shame Apple f-ed up Catalina (and earlier versions, in this particular case), but we have no good leads here apart from rewriting aw-watcher-window hoping that it'll fix it. So for those versions that we apparently don't yet support for the Help contribute a fix. We still welcome contributions that can resolve this, see the discussion in the aw-watcher-window PR here: ActivityWatch/aw-watcher-window#40 |
I guess a valid point here is that people who have older versions than Catalina and have installed ActivityWatch through a As for the users (including @officerats ) : somewhat because of Apple's tight protection I've been unable to even set up a pre-catalina virtual machine (all my macOS devices run Catalina now) so haven't been able to test these exact problems. It is annoying for sure though for everyone who can't upgrade to Catalina just yet. |
Looks like someone asked about this on the Apple Stack Exchange: https://apple.stackexchange.com/questions/385104/activitywatch-app-wants-access-to-control-system-events-app-dialogs |
That's strange. I'm facing that with osX 10.14.6 (18G87) as well. |
I've been launching activity watch with |
@8bitgentleman Maybe it's the same as this issue? Nothing has changed in the code recently, but next version will improve the permission handling on macOS. Hopefully that works around the issue, but who knows. If you want to verify it early you can build aw-watcher-window from source. https://github.com/ActivityWatch/aw-watcher-window/pull/41/files |
@johan-bjareholt sounds like a more extreme example of that issue. Instead of a stutter it's a full blown system hang. Hopefully the next version will help |
in addition to fixing this issue, I wanted to have ActivityWatch start at login. I just wanted to confirm that the workaround described above (nohup not needed) works following the Automator or LaunchAgents solutions here https://stackoverflow.com/questions/6442364/running-script-upon-login-mac which makes me feel like just wrapping the startup in any other process fixes this problem. I think this means that this workaround could be shipped rather easily and only executed on MacOS version detection or just prompting the user on initial startup. I have a Mojave, so I could test PRs and such given the time (and perhaps some guidance if you'd like this expedited) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
[Bump for stale bot] Confirming existence of this problem in version 0.10.0 |
Same issue here in version 0.10.0 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Describe the bug
Just installed the new version (9) on Mojave for the first time. After the app opens ActivityWatch continues to spam me with messages to control "System Events" even after I have given the app permission under
Security & Privacy > Automation
as well as Security & Privacy > Accessibility`.This also causes a noticeable lag/slowness for the operating system as a whole.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I should only need to grant the app permission once and the app should not cause my computer to stutter.
Documentation
aw-qt_2020-03-19T12-56-05.log
aw-watcher-window_2020-03-19T12-56-05.log
aw-server_2020-03-19T12-56-05.log
Environment
The text was updated successfully, but these errors were encountered: