Activitywatch: macOS - Continual "Control System Events" Message

[8bitgentleman]

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:

1. Open the app on macOS

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

• ActivityWatch version: v0.9.dev+c815323
• OS: [macOS (Mojave)]

[xylix]

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.

[8bitgentleman]

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

[ErikBjare]

@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?

[8bitgentleman]

@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

[ErikBjare]

That's really helpful to know, thanks! We'll look into it.

[xylix]

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.

[8bitgentleman]

@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

[xylix]

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 :).

[xylix]

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.

[ErikBjare]

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, [e-mail]
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
https://github.com/ActivityWatch/activitywatch/issues/380#issuecomment-602015284,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKXDOVTVYLDONKR2DFEKGTRIR5PPANCNFSM4LPOA4GQ
.

[xylix]

That would explain it. I'll take a look. It could be possible with pyobjc.

[8bitgentleman]

@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!

[johan-bjareholt]

@ErikBjare @xylix Maybe revive this old PR then? https://github.com/ActivityWatch/aw-watcher-window/pull/29

[xylix]

@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.

[8bitgentleman]

@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).
I am running v0.9.2

[xylix]

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.

[lxndrcx]

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.
When I run aw-qt on the command line i.e. /usr/local/Caskroom/activitywatch/0.9.2/ActivityWatch.app/Contents/MacOS/aw-qt it runs correctly.

[officerats]

Same issue on macOS 10.14.6, ActivityWatch version 0.9.2.

aw-watcher-window makes tccd eat lots of CPU, causing lags, and spams with the same dialogue, asking to allow access to control system events, even though it's already enabled in security & privacy settings.

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.

[johan-bjareholt]

And on another note, maybe another issue though, not sure, ActivityWatch detects VSCode as "Electron" in top apps list.

That's an vscode bug that it seems like they will never fix.

https://github.com/Microsoft/vscode/issues/46762

[officerats]

@johan-bjareholt understood, sad indeed.
Would it be possible to detect if aw-watcher-vscode is running and replace Electron with VSCode as a workaround?

[officerats]

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.
My steps:
1) download, unpack
2) run ./aw-qt from iTerm
3) it asks same permission to "Control System Events", but for iTerm, not for ActivityWatcher, since the parent process is zsh from iTerm
4) works normally: no freezes, no permission dialog spam and detects window's titles correctly, as opposed to bundled .app

I decided to also check how it works from bundled app:
1) cd /Applications/ActivityWatch.app/Contents/MacOS/
2) ./aw-qt

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

[xylix]

Thanks for good description of the workaround. I still haven't been able to reproduce the Control System Events so it's been hard to debug. It seems to only happen in macOS versions older than Catalina. Catalina has it's own different problems.

I'll be taking a better look on sunday, let me know if you come up with anything.

[officerats]

Unfortunately, I can't help more as I don't have experience on macOS development whatsoever.
My uneducated guess, judging by what's said in this thread, is that when you spawn said AppleScript from window watcher it somehow doesn't inherit the permissions from the parent process/bundle and fails to get window title(empty entry in web UI).

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:
1) either ActivityWatch bundle is configured in a way that it doesn't allow permission inheritance for subprocesses
2) or when run from iTerm2 it actually has correct parent(iTerm2), but who's the parent when you launch the bundle from Finder/Spotlight?

I'm not sure if what I'm talking about makes sense, just throwing it out there.

[8bitgentleman]

1. cd /Applications/ActivityWatch.app/Contents/MacOS/
2. ./aw-qt

Is there a way from running this from the terminal where I don't need to keep the terminal app open? If I just run ./aw-qt quitting terminal quits ActivityWatch

[xylix]

@8bitgentleman Yeah with nohup. (https://linux.101hacks.com/unix/nohup-command/ )
nohup aw-qt & will start it allowing for it to run after the terminal has been quit and detach it. For extra info see https://github.com/ActivityWatch/activitywatch/issues/323

@officerats Thanks for the guesses,

1. Is possible, but that should also cause this problem on other macos installations, which isn't the case. I have multiple working catalina installations and have had users report it's working too.
   
   
   
   1. shouldn't really be the problem. The App should be it's own "parent" when it's launched from the ui / with open ActivityWatch.app form terminal.
   
   

[8bitgentleman]

Thanks @xylix wow that's very bizarre, launching it with nohup ./aw-qt & runs activity watch, including the window watcher, with no noticeable lag or incessant permission pop-ups

[ErikBjare]

Removing high priority label as it only appears to happen on Mojave and there is a workaround.

[officerats]

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?

[johan-bjareholt]

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?

[ErikBjare]

@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 .app bundle (which is brand new, by the way): use the workaround, or...

Help contribute a fix. We still welcome contributions that can resolve this, see the discussion in the aw-watcher-window PR here: https://github.com/ActivityWatch/aw-watcher-window/pull/40

[xylix]

@johan-bjareholt @ErikBjare

I guess a valid point here is that people who have older versions than Catalina and have installed ActivityWatch through a brew cask (which is maintained by a third party maintainer AFAIK) will automatically get udpated to the latest ActivityWatch version, and this seems to cause problems on some installs. Could be useful to have an actual in-app "warning" or info popup about the workarounds for these cases.

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.

[ErikBjare]

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

[luckydonald]

That's strange. I'm facing that with osX 10.14.6 (18G87) as well.
Used brew cask install activitywatch, it installed an app claiming to be 0.9.0.
It is now repeatedly asking me that.
My older install, which is just the 0.8.0b7 release zipfile unpacked in the Downloads folder works without bugging me repeatedly..

[8bitgentleman]

I've been launching activity watch with nohup ./aw-qt & command as suggested by @xylix with no issues since it was suggested here. Today after a reboot I ran the command as normal. After activity watch launched Mac began to intermittently hang. I can move the mouse just fine but cannot interact with anything else for several minutes with a brief ~30 second window where everything acts as normal. Without launching activity watch this does not occur. Has something changed recently?

[johan-bjareholt]

Today after a reboot I ran the command as normal. After activity watch launched Mac began to intermittently hang. I can move the mouse just fine but cannot interact with anything else for several minutes with a brief ~30 second window where everything acts as normal. Without launching activity watch this does not occur. Has something changed recently?

@8bitgentleman Maybe it's the same as this issue?

https://github.com/ActivityWatch/activitywatch/issues/411

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

[8bitgentleman]

@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

[Chovin]

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)