Skip to content
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

Feature request: Allow multiple chrome browser with separate logs #82

Open
akademy opened this issue Feb 21, 2022 · 5 comments
Open

Feature request: Allow multiple chrome browser with separate logs #82

akademy opened this issue Feb 21, 2022 · 5 comments

Comments

@akademy
Copy link

akademy commented Feb 21, 2022

I currently use Vivaldi with two profiles, one for work, one for home, but they both get recorded into a single ActivityWatch bucket. (You can install different extensions into each profile).

I would like to be able to customise the bucket name so that the recorded tabs I use are recorded separately.

(FYI, if anyone would like to do this themselves, find the app.js in the Extensions folder of your browser, and edit line 3329 (on version 0.4.3.0) to something else other than "aw-watcher-web-" + browserName.toLowerCase();)

Thanks for you work. 😄 👍

@akademy akademy changed the title Allow multiple chrome browser with separate logs Feature request: Allow multiple chrome browser with separate logs Feb 21, 2022
@Morpheus0x
Copy link
Contributor

Morpheus0x commented Jan 11, 2023

I am currently working on implementing this. The user will have the option to set a custom bucket ID from the extension popup. It would have been nice to automatically detect the profile name in Firefox and use that, but unfortunately this isn't the case. I am thinking of using a simple hash function on current time and use the first 6 digits as the default ID on install.

Edit: Using Enterprise Policy, the user can specify not to enable the watcher by default. This will allow for changing the bucket ID before it is registered, which prevents possible double bucket creation in ActivityWatch. However, I think this will only work in Firefox, a similar solution for Chrome would be nice. As far as I know, the equivalent of Firefox Enterprise Policy in Chrome doesn't provide a way to configure extensions.

Edit 2: Possible solution: just use the default bucket ID, without defaulting to a custom name with hash. The user can then choose after installation to change the default name.

@akademy
Copy link
Author

akademy commented Jan 20, 2023

Great work 👍

@akademy akademy closed this as completed Jan 20, 2023
@Morpheus0x
Copy link
Contributor

@akademy This pull request doesn't fix the issure raised here I just mentioned it, please reopen. I am currently working on a PR for this

@akademy akademy reopened this Jan 21, 2023
@heroje
Copy link

heroje commented Feb 20, 2024

It would have been nice to automatically detect the profile name in Firefox and use that, but unfortunately this isn't the case.
@Morpheus0x

I am not familiar with developing extensions, but it reminds me of how another extension handled recognition of Firefox profiles by running an external program:
https://github.com/null-dev/firefox-profile-switcher
https://github.com/null-dev/firefox-profile-switcher-connector

I hope this helps in some way. I'm running separate Firefox profiles at almost all times, and only one of them is able to record data in AW at this moment.

@paulirish
Copy link

(FYI, if anyone would like to do this themselves, find the app.js in the Extensions folder of your browser, and edit line 3329 (on version 0.4.3.0) to something else other than "aw-watcher-web-" + browserName.toLowerCase();)

This is the updated version that allows this to work:

diff --git a/manifest.json b/manifest.json
index 924e6a8..5096fe9 100644
--- a/manifest.json
+++ b/manifest.json
@@ -14,11 +14,7 @@
     "default_popup": "static/popup.html"
   },
 
+  "key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvXL8aewYb9SqcN84b8Ptw7BiSTPppTzsk/vrk6yzvuRITaU3O3nSNCWKLPVIMYk5Zz3MyXHmVFqFtfyM6CvwS+bCqR7iXMt+anFbqaW7y5yhzkxUN0IVGLCK5KJMPmCJ64rN8C4oG7FaeBQOKQX4VHCexWcBKfR2nUdV1czXJ3CrKuigD/6uEgvuXf2sKlvrPuaZqgjSmWQiPKjycmZrDuS1lxB9ThvPct3bOKNCikjnrCrvF6p86f6/q7p6ZitmGGZI/4qcRN9/3xC/pV0Ix8CTCwHUXyGaTlKvb9VFipj4x5DLacZB/JfWSJgxaerkGuLFD796oPITrbTqtif6PQIDAQAB",
 
   "background": {
     "scripts": [
diff --git a/src/client.js b/src/client.js
index 3a1fd6d..c8b2085 100644
--- a/src/client.js
+++ b/src/client.js
@@ -43,7 +43,8 @@ var client = {
     client.browserName = getBrowserName();
     // Check if in dev mode
     chrome.management.getSelf(function(info) {
-      client.testing = info.installType === "development";
+      // Despite loading as unpacked, otherwise treat this as the normal published extension
+      client.testing = false; 
       console.log("testing: " + client.testing);
 
       client.awc = new AWClient("aw-client-web", {testing: client.testing});
@@ -55,7 +56,8 @@ var client = {
   },
 
   getBucketId: function () {
-    return "aw-watcher-web-" + client.browserName.toLowerCase();
+    // Adjust to suit your needs…
+    return "aw-watcher-web-canary-" + client.browserName.toLowerCase();
   },
 
   updateSyncStatus: function(){

The specific key there allows this extension to be loaded as unpacked (in developer mode), BUT still use the 'production' chrome extension ID nglaklhklhcoonedhgnpgddginnjdadi. That's necessary now due to this check.

(Disclaimer: i don't really know what testing mode is really for, so perhaps using that is easier. But I just wanted to minimally fix this without worrying about the server running on a different port, etc.. )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants