Did you install the web extension?

Yes, installed and active.

I think I know what the issue is. We just need to add "Brave Browser" here: https://github.com/ActivityWatch/aw-webui/blob/0036b4860fb52f428e7e14fdba1fe22950e17db8/src/queries.ts#L124

@bawasi Can you confirm if the bucket name (on the "Raw Data" page) is aw-watcher-web-chrome or aw-watcher-web-brave?

I am having the same issue with seeing no browser data from Brave. My bucket id is aw-watcher-web-chrome.

Yes, bucket id is also for me aw-watcher-web-chrome

@ErikBjare It should not be added to the "brave" dict, older versions of brave for a short while had that but removed it because they had incompatibilities with some sites. The developers instead made their own exotic API for others to detect if the user is running or brave or not instead of following internet standards.

brave/brave-browser#1052 (comment)

So the only possible solution to this is to add it to the "chrome" section, but if any user has both chrome and brave running at the same time your activity will be completely wrong because now two watchers will write to the same bucket at the same time creating invalid data.

So brave developers has essentially shot themselves in the foot by tricking every website that they are chrome even if they are not. For most sites that fixes issues, but in our case that's exactly what breaks our use-case. The responsible thing for Brave would have been to be honest that it's in fact brave and if some site works fine on brave but lies that it's incompatible it could have had a "whitelist" for those sites so it only fakes it on those specific sites. But they have gone the easy route and trick everyone instead of just the bad actors.

I am considering if we should just remove Brave support completely and refer to that GitHub issue upstream (others have reported that it has worked on Linux, but also complained about the bug when running both brave and chrome).

@johan-bjareholt That's pretty crazy.

If you want to deal with upstream that's all good but I think we're good with just saying "because Brave doesn't want anyone to know that their users are using Brave, watching both Chrome and Brave at the same time leads to undefined behavior", and then go ahead and keep putting Brave in the "chrome" field anyway.

Does this mean we should move the existing Brave entry into the chrome field? I guess it's useless right now?

Flooding might partially fix it for those few cases that watch Chrome and Brave simultaneously, so it wouldn't be worthless, just kinda corrupted/inaccurate.

Edit: After reading that issue, aren't there more reliable ways to figure out the browser name than checking the User-Agent?

Does this mean we should move the existing Brave entry into the chrome field? I guess it's useless right now?

Yes

Flooding might partially fix it for those few cases that watch Chrome and Brave simultaneously, so it wouldn't be worthless, just kinda corrupted/inaccurate.

The URLs and titles would be correct, but "kinda corrupted/inaccurate" is an understatement as the durations would be completely wrong.
If both watchers heartbeat at the same time all the time (which will be the case because aw-watcher-web is not aware if the user is afk or not) they will take turns on sending heartbeats making most heartbeats a new unique event instead of actually merging them resulting in a bucket getting filled rather quickly. The durations will be completely random as both write at the same time but will most likely average out to be 50% brave and 50% chrome even though you might be using brave 95% of the time.

Edit: After reading that issue, aren't there more reliable ways to figure out the browser name than checking the User-Agent?

Not that is compatible with all browsers. User-Agents are already complicated as is, which is why we use the ua-parse library in aw-watcher-web. We could use braves unique API to find out whether it's brave or not, but I'd prefer to avoid having brave specific code.

function isBraveUA () {
  if (!window.Promise) {
    return false;
  }
  if (typeof navigator.brave == "undefined" ||
      typeof navigator.brave.isBrave != "function")
  {
    return new Promise(function (resolve) {
      resolve(false);
    });
  }
  return navigator.brave.isBrave()
    .then((response) => {
      return response;
    })
    .catch((error) => {
      return false;
    });
}

Any updates on this? For some reason URLs show up correctly in 'aw-watcher-web-chrome' in Timeline tab, but not in Activity tab, just like OP's screenshot

Perhaps the temporary hard-coded solution could be used until ua-parse supports brave?

I assume ua-parse will never be fixed because it's not broken, brave wants itself to be disguised as chrome in the user agent and that's what ua-parse parses.

It would certainly be possible to use the brave specific code, but then we should also ask if we should add the vivaldi specific code too. Then maybe in the future there's yet another browser disguising itself at chrome (maybe Opera?) which needs a specific fix and then suddenly we have a lot more to handle than just brave.

If there's some actively maintained library that handle these I'd be happy to take in a change which uses that instead. I haven't looked at that though.

I see your point, but besides the philosophical question and code purity, you have an actual situation, which is not difficult to fix technically. You have actual users, having a very real-world issue. That is, part of the ActivityWatch doesn't work correctly because it doesn't recognize a browser. Is it realistic to expect people to ditch Brave just so ActivityWatch would work for them? Isn't software supposed to hide these issues away from us? In my view, the code itself is not the point of software, solving real-world problems is. :) Often, if the library doesn't do it for us, we get around that by writing custom code.

I see your point, but besides the philosophical question and code purity, you have an actual situation, which is not difficult to fix technically.

@tihomir-kit This is not a philosophical question or about 'code purity', it's about the very practical matter of us not having the time (nor the personal motivation) to maintain hacky workarounds which are doomed to break every once in a while.

Me and @johan-bjareholt simply don't want to maintain a browser identification library, especially when certain browser vendors have their own reasons to make it hard to identify a browser (to avoid fingerprinting, and websites blocking "unsupported" browsers). Frankly, our time is better spent elsewhere.

Is it realistic to expect people to ditch Brave just so ActivityWatch would work for them?

No, but it is expected that people who use these browsers (which don't follow standards) to themselves contribute and maintain fixes for them. The source is open. So if you need a fix, fix it and make a PR 🙂

Ok, I thought the issue was more of you not wanting to have that workaround code inside the application at all. But what you're saying is if someone implements a workaround / custom agent identification in a form of PR, you will accept it?

I just tried to say that I'd like to avoid having it in the application as I expect it to become a maintenance burden even if someone else implements it. But as long as we are clear that brave isn't "officially" supported and the code isn't significantly complicated (which it doesn't seem to be) I'm fine with taking in such a workaround. I just don't find it to be worth my time to implement it myself.

Hello!

I know the issue is open, and will likely never be fix, but you mentioned a hacky workaround that would break everything if someone used Chrome and Brave at the same time, but otherwise would make the Top Domains work for Brave.

Is this something that would be easy to do by myself? I don't use chrome, so I'm not worried about the bug, and I would love to get the view working for Brave. And I don't mind making small changes to the extension/configuration by myself.

But what exactly is the issue? The Web extension from Brave is already logging data "correctly" into the aw-watcher-web-chrome, so the issue with two browsers writing into the same bucket would arise anyway. But the Top Domains visualization is still not displaying the data, even through they are there in the bucket. I though the Top Domains should've just aggregated data from all web-related buckets, and it shouldn't matter what browser are you viewing them from. The data are already there, in the chrome bucket, and logged correctly. So what's preventing them from displaying?

Edit: I was able to figure out a workaround, by reimporting the chrome bucket as aw-watcher-web-brave (using export as JSON, Find-Replace and reimporting back in), and by hardcoding the same bucket name into the Chrome extension (getBucketId in app.js), instead of letting the extension to figure out the browser by itself. While it's a hacky workaround that's no way near PR-worthy, it may help some people who are trying to solve the same issue.

@MikulasHrdlicka It should be possible to fix this without breaking chrome if it's running at the same time.

How to detect if it's brave rather than chrome is badly documented here: brave/brave-browser#8216

Same problem with the Vivaldi browser. After I connected the server from Chrome, it starts to show the data list.

Maybe it would be possible to let the user select (in the settings of the extension) the browser they are running it in?

FYI, I've found the workaround mentioned by MikulasHrdlicka to still work. I couldn't get the json import to work using the latest beta release so I had to roll back to the stable 11.0 release that I'd initially exported the json with (did the JSON format change or something between versions?).

I hardcoded the bucket name in to the Chrome extension app.js as so:

getBucketId: function() {
    // TODO: This works for Chrome and Firefox, but is a bit hacky and wont work in the general case
    var browserName = client.getBrowserName();
    return "aw-watcher-web-brave";
  },

I did run in to an issue where loading the extension as an unpacked extension caused it to go in to testing mode which only attempts to use port 5666 for the rust server, which failed because I'm not using the rust server because apparently there is some database migration incompatibility or something? Anything where the database has to be migrated but then on restart the program goes back to using the old database sounds like a bad time to me so I didn't try it. Thus, I also had to hardcode the extension to use port 5600.

if (typeof options.baseURL === "undefined") {
            const port = !options.testing ? 5600 : 5600;
            this.baseURL = `http://localhost:${port}`;
        }

I also found the process of being able to import the json files a bit fiddly. It felt like I had to stop the browser, window and afk watchers so I could delete all the existing buckets, so then I could import the json file, and then start the watchers back up.

All the above said, the workaround does work so I'm reasonably happy.

I'm talking about things I know nothing about, but if Brave is hard to detect normally, I'd be totally fine if there was just an extension setting for "What browser do you identify as?" Or perhaps it could keep just detecting as Chrome but then on first run it generates an browser "ID" of a few random characters that get appended to the bucket name? LIke "aw-watcher-web-chrome-F3A9" could end up as one browser like Brave and "aw-watcher-web-chrome-B392" could be a different browser like Chrome. At least then you don't end up with database collisions. I'm sure this creates new issues where a browser/extension reinstall generates a new random ID and thus all the data starts going in to a new different bucket.

I think I know what the issue is. We just need to add "Brave Browser" here: https://github.com/ActivityWatch/aw-webui/blob/0036b4860fb52f428e7e14fdba1fe22950e17db8/src/queries.ts#L124

@bawasi Can you confirm if the bucket name (on the "Raw Data" page) is aw-watcher-web-chrome or aw-watcher-web-brave?

Can this be done? :) I can confirm that on Mac OS it's "Brave Browser":

Meanwhile, I am just editing /Applications/Brave Browser.app/Contents/Info.plist like this which also makes it work:

Seems to me that this bug causes the "audible browser tabs don't count as AFK" feature to not work. That feature was merged here: ActivityWatch/aw-webui#262

The tab activity is being marked as audible, but I think since the browser watcher isn't working it fails to qualify for the AFK exception. I think the relevant code might be around this area: https://github.com/ActivityWatch/aw-webui/pull/262/files#diff-97651250ee5b39a1d46e9d92b574a8d7ee98ebb31335fb8bc3ee072641097f9aR73-R78

Can anyone else confirm?

This feature might be a workaround, but it doesn't seem to be released yet, at least not on 0.12.1 which is latest: ActivityWatch/aw-webui#375

For a quick hack you can

1. Add Brave Browser there:
   https://github.com/ActivityWatch/aw-webui/blob/7d4438f3e83fac3ce09e5fa0c72cc8ddb105de69/src/queries.ts#L235
2. Build web UI and copy dist -> aw-server/as_server/static
3. Run one more aw-server on a custom port

For a quick hack you can

1. Add Brave Browser there:
   https://github.com/ActivityWatch/aw-webui/blob/7d4438f3e83fac3ce09e5fa0c72cc8ddb105de69/src/queries.ts#L235
2. Build web UI and copy dist -> aw-server/as_server/static
3. Run one more aw-server on a custom port

Thanks a lot @fbjorn ! Works like a charm.

ActivityWatch contributors: I see the last comment before mine has been added as @fbjorn noted as a fix. I still am experiencing this issue with Brave and not seeing any activity and it seems to have been an issue for nearly 4 years now with a lot of chatter I couldn't dive into because I didn't know if it was any longer relevant.

In the short of it I have tried the "workaround" of setting: brave://flags/#enable-experimental-web-platform-features to Enabled but still nothing. My Raw Data reflects wonderful data that is accurate but doesn't bubble up to the Activity / Browser section whatsoever.

I think rather than eliminating Brave support entirely a better route would be to tell users a disclaimer:

NOTE: If you are using Chrome and Brave simultaneously it could result in garbled results.

Rather than lose support for Brave altogether, why not simply make a note of this edge case, which is how I am reading this is going. I think there are far less users worried about mixing between usage of Chrome with Brave than there are Brave users wanting this to "Just Work"™ and likely do not spend much, if any, time in the two browsers.

Let me know if I am digesting this correctly but this seems like a viable solution if I have groked enough I have poured through over the past 3-4 years of this issue. It really is readily apparent seeing you've all been trying really hard and taking a whack at this but I say just throw up a Disclaimer and throw in the towel on it. Thanks guys!

...

Meanwhile, I am just editing /Applications/Brave Browser.app/Contents/Info.plist like this which also makes it work:

I am also doing this. Just have to restart both brave and AW. 1password extension complained that the browser changed but I just had to sign in again and it was cool.

It seems the used library for browser detection in aw-watcher-web properly detects Brave. Awaiting merge of ActivityWatch/aw-webui#283, that should fix this issue.

I still don't see browser data being populated. Are there any other steps we need to follow on Brave?

@rohitsathish You have to wait for a new release of the web extension, which might unfortunately take a while.