ActivityWatch / aw-watcher-web

Browser watcher for ActivityWatch
Mozilla Public License 2.0
319 stars 46 forks source link

Problem with chrome extention #77

Open felixgouin opened 2 years ago

felixgouin commented 2 years ago

Acitvity Watch didn't report my webbrowser (in the "broswer" tab) stats with the chrome extention in Vivaldi 4.3.2439.44 (Stable channel) (64 bits) (chromium based browser)

CowboyBebop commented 2 years ago

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?

johan-bjareholt commented 2 years ago

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

https://github.com/ActivityWatch/activitywatch/issues/461#issuecomment-666639858

M1zzu commented 2 years ago

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: https://github.com/ActivityWatch/activitywatch/issues/321#issuecomment-1004849942), since auto-detection of Browser seems not possible anymore. I may be willing to implement that.

johan-bjareholt commented 2 years ago

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

M1zzu commented 2 years ago

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

baddwin commented 2 years ago

Just to add, it occurs also in chromium-freeworld