Same here, tested with 0.4.3 web watcher (what is on the chrome web store atm) with the nightly build from (https://github.com/ActivityWatch/activitywatch/actions/runs/1426831007).

on Chrome works perfectly fine, on Vivaldi does not track anything.

This has been mentioned on #29 and seemingly resolved but looks like the problem persists, could be the store version is not updated since then?

This is due to Vivaldi pretends to be chrome, making it impossible for us to know if the user is actually using chrome or is using Vivaldi. Same issue exists for Brave browser. See following thread

ActivityWatch/activitywatch#461 (comment)

I tried to do a local hack by just statically returning "vivaldi" in getBrowserName() in client.js and loading that local extension in dev mode after a make build, though now I get CONNECTION_REFUSED from the backend. Pseudo-edit: Oh, I get that even if I rollback that change, and load current master from a local repo. Popup says "Extension is running in testing mode", maybe the backend refuses such POSTs by default? Requests look quite different in DevTools compared to the ones from the live extension from the store.

I guess one actually-proper-but-still-dirty-ish solution to at least get it working would be to add some kind of flag for the user to configure in the popup (as described in the first paragraph of this comment: ActivityWatch/activitywatch#321 (comment)), since auto-detection of Browser seems not possible anymore. I may be willing to implement that.

@M1zzu When in testing mode, the port 5666 is used instead för 5600. This is so you don't mess up your "real" data while developing. To start aw-server in testing mode, start it with the "--testing" flag.

Thanks! Funnily enough I was just trying to look into it and noticed that. Now at least I got my local hack working (which just overrides stuff in the source code and then I load the extension in chrome dev mode).

Just to add, it occurs also in chromium-freeworld