fix(queries): match Dia/Arc chrome forks and surface empty Browser view

[TimeToBuildBob]

Fixes #927. Complements #928 (same regex, plus the Dia bundle id and a visible empty-state).

Problem

The Browser view (Top Domains / URLs / Titles) is permanently empty in Chromium forks such as Dia. The extension works and events land in aw-watcher-web-chrome_<host>, but browserEvents() intersects those against window events whose app must match the chrome entry in src/queries.ts. Forks report themselves as "Dia" / "Arc" (and on macOS Dia, bundle id company.thebrowser.dia), so filter_period_intersect returns nothing and all three columns render "No data" with no error.

This is the same failure mode as ActivityWatch/activitywatch#1094 (Arc). A standalone arc/dia key cannot bind: browsersWithBuckets() matches on bucket id substring, and the chrome build of the extension never produces a bucket containing "arc" or "dia" unless the user overrides the browser name in the extension settings.

What this PR does

1. Match forks through the chrome bucket (the one they actually write to):
   • Add arc and dia process-name alternatives to browser_appname_regex.chrome, each $-anchored so names like archive / Dialog do not match.
   • Add company.thebrowser.dia to browser_appnames.chrome (macOS bundle id; reverse-domain names are not matched by the process-name regex).
   • Leave the standalone arc key in place for the settings-override case.
2. Stop the silent empty. When a browser watcher bucket exists but the window-event intersection is empty, the Browser visualizations now show an info hint pointing at Browser view empty in Dia (Chromium fork, reports app name "Dia") #927 instead of a bare "No data". This also covers the honest "didn't browse this period" case.

The regex half follows the diagnosis and patch from @TiberiusNemesis in #927 / #928. This PR adds the bundle-id path they also confirmed, plus the empty-state so the next fork reports itself instead of looking like a broken install.

Tests

• Chrome regex covers Dia / Arc and rejects Dialog / archive.
• Exact list contains company.thebrowser.dia.
• Generated chrome-bucket query includes both the bundle id and the process-name regex.
• isBrowserAllowlistMiss covers the empty / loading / no-bucket / matched cases.

npx jest --selectProjects node --testPathPattern='(queries.test.node.ts|browserAllowlist.test.node.ts)$' — 28 passed.

Out of scope

Helium is already a standalone key on master (net.imput.helium). If Helium also writes to the chrome bucket by default, that is the same bug and belongs with #898 rather than this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 53.74%. Comparing base (a2ca625) to head (420d0bd).
⚠️ Report is 12 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #949      +/-   ##
==========================================
+ Coverage   51.99%   53.74%   +1.74%     
==========================================
  Files          48       49       +1     
  Lines        2927     3003      +76     
  Branches      652      719      +67     
==========================================
+ Hits         1522     1614      +92     
+ Misses       1385     1310      -75     
- Partials       20       79      +59     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[greptile-apps]

Greptile Summary

The PR expands Chrome-bucket window matching to recognize Dia and Arc and adds a localized explanation when Browser analytics resolve without matching activity.

• Adds Dia and Arc process-name matching plus Dia’s macOS bundle identifier.
• Deduplicates the Chrome/standalone-Arc pair while continuing to concatenate unrelated browser streams.
• Adds the Browser empty-state predicate, localized messages, and query-generation regression tests.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/queries.ts	Extends Chrome-bucket matching for Dia and Arc and limits overlap-union behavior to the potentially duplicate Chrome/Arc pair.
src/components/SelectableVisualization.vue	Displays the localized allowlist explanation for resolved empty Browser visualizations.
src/util/browserAllowlist.ts	Defines the predicate distinguishing a resolved empty Browser query from loading or unavailable states.
test/unit/queries.test.node.ts	Covers fork matching and generated-query combination behavior for Chrome, Arc, and unrelated browsers.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  Buckets[Browser watcher buckets] --> Detect[Detect browser bucket types]
  Detect --> Query[Intersect browser events with matching active windows]
  Query --> Pair{Chrome and standalone Arc both present?}
  Pair -->|Yes| Union[Deduplicate Chrome and Arc streams]
  Pair -->|No| Concat[Concatenate browser stream]
  Union --> Others[Concatenate unrelated browser streams]
  Concat --> Results[Domain, URL, title, and duration summaries]
  Others --> Results
  Results --> Empty{Browser bucket available but result empty?}
  Empty -->|Yes| Hint[Show localized allowlist hint]
  Empty -->|No| Visualizations[Render Browser visualizations]

Loading

_{Reviews (5): Last reviewed commit: "fix(queries): union only chrome+Arc dupl..." | Re-trigger Greptile}

[TimeToBuildBob]

CI-green and mergeable — waiting only on a maintainer click.

This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted.

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

Current head 17feed1 is fully converged: all nine CI/CodeQL/Greptile checks pass, Greptile reviewed this exact head at 5/5 with no blocking findings, and GitHub reports it cleanly mergeable. Bob still has pull-only access here, so the remaining action is maintainer review/merge.

[ErikBjare]

@TimeToBuildBob Merged #928, address conflicts

[TimeToBuildBob]

Rebased onto master, then scoped union_no_overlap to the chrome+Arc duplicate pair (head 514a1fc). Conflicts were the overlapping chrome regex/tests from #928 — kept that regex as landed.

What's in this PR:

• company.thebrowser.dia on the exact chrome list (macOS bundle id; reverse-domain names still don't match the process-name regex)
• empty-state hint when a watcher bucket exists but the window intersection is empty
• union_no_overlap only for chrome + standalone Arc (other browsers still concat)
• Swedish browserAllowlistMiss (sv.ts landed on master after this PR opened)

CI green, Greptile 5/5. Bob has pull-only access here — remaining action is maintainer review/merge.

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

@greptileai review

[TimeToBuildBob]

Rebased onto current master and force-pushed head 8cf736b. The only conflict was the shared import block in test/unit/queries.test.node.ts; I kept both master’s newer appQuery/categoryQuery regression coverage and this PR’s browser_appnames/fullDesktopQuery coverage.

Verified locally: 29 targeted tests pass across queries.test.node.ts and browserAllowlist.test.node.ts. GitHub now reports the PR mergeable; fresh CI is running.

[TimeToBuildBob]

Rebased onto current master (post-PR #952 feat(categories): field-scoped regex). The only conflict was the import block in test/unit/queries.test.node.ts — HEAD added canonicalEvents, this PR needed browser_appnames + fullDesktopQuery; kept both. New head 06d1d87, GitHub reports MERGEABLE/CLEAN.

[TimeToBuildBob]

🤖 AI code review

Safe to merge — 1 P1 disposed (accepted-tradeoff)

_{Updated after inline dispositions on finding threads — this is the current state; the verdict below is frozen at review time and is kept as the historical record of that pass.}

Finding disposition

Finding	Severity	State
src/queries.ts:324	P1	superseded by latest review (not reproduced)
src/queries.ts:388	P1	accepted-tradeoff
src/queries.ts:384	P2	superseded by latest review (not reproduced)
src/util/browserAllowlist.ts:20	P2	accepted-tradeoff

Not safe to merge — 1 P1 open

Confidence 3/5

_{ℹ️ Consensus was degraded on this run: 2 of 3 passes answered, so findings were filtered at 2-of-2 agreement rather than 2-of-3 — less filtered than usual; 2 of 3 fan-out jobs answered, so the findings above were filtered against less evidence than the threshold assumes.}

2 findings · ❌ 1 P1 · ⚠️ 1 P2

❌ P1 high — src/queries.ts:388

In browserEvents(), the chrome regex is rebuilt with chromeAppnameRegex(dedicatedChromeForks) when any dedicated fork bucket exists. dedicatedChromeForks is computed from browsersWithBuckets(params.bid_browsers), which maps over Object.keys(browser_appnames) and finds a bucket whose ID includes the browser name. The bucket ID matching uses _.includes(bucket_id, browserName), so a bucket named 'aw-watcher-web-chrome_testhost' matches 'chrome', and 'aw-watcher-web-arc_testhost' matches 'arc'. However, the chrome bucket ID also contains the substring 'chrome' in 'aw-watcher-web-chrome', and the arc bucket ID 'aw-watcher-web-arc' does not contain 'chrome', so that's fine. But consider a bucket named 'aw-watcher-web-chromium_testhost' — it contains 'chrome'? No, 'chromium' does not contain 'chrome' as a substring? Actually 'chromium' contains 'chrom' but not 'chrome'. So no. The real issue: the exclusion logic only strips forks that have a dedicated bucket, but the dedicated fork bucket's events are also matched by the chrome regex if the fork's app name appears in the chrome bucket. The comment says 'A settings-override Arc bucket can coexist with the default chrome bucket, and then the same Arc activity would be counted by both streams.' The fix strips Arc from the chrome regex, but the Arc bucket's own regex is '(?i)^arc(.exe)?$' which matches 'Arc' and 'arc.exe'. However, the Arc bucket's events are also filtered by filter_keyvals with browser_appnames.arc which is empty, so only the regex path matches. The chrome stream now excludes Arc, so no double count. But what about Dia? Dia has no dedicated bucket, so it stays on chrome. That's intended. The bug: the exclusion is based on the presence of a dedicated bucket, but the dedicated bucket might be for a different host or a stale bucket. More concretely, if a user has both a chrome bucket and an arc bucket, but the arc bucket is empty or from a different host, the chrome regex drops Arc, so Arc events in the chrome bucket are no longer counted, even though the arc bucket contributes nothing. This is a real regression: a user with an old arc bucket that has no events in the period will lose all Arc browsing data from the chrome bucket. The condition should check whether the dedicated bucket actually contains events in the period, but the query generation cannot know that. This is a design trade-off, but the consequence is that Arc users with a stale/empty arc bucket silently lose Arc data. The PR's own test only checks the generated query text, not the actual data outcome.

_{How this was verified: Traced browsersWithBuckets: it finds a bucket for each browser name if any bid_browsers entry includes the name. If an arc bucket exists but has no events in the period, the chrome regex still excludes arc, so Arc events in the chrome bucket are dropped. The generated query has no way to conditionally include based on bucket content.}

_{Consensus: 2/2 passes agreed}
Distinct keys: 1 (general)

⚠️ P2 medium — src/util/browserAllowlist.ts:20

The new browserAllowlistMiss hint fires whenever browser.duration === 0 and top_domains is an empty array, regardless of whether the browser watcher actually recorded any events. In the honest 'didn't browse this period' case, the user simply didn't use a browser, and the hint text says 'If you were browsing in a Chromium/Firefox fork, its app name may not be recognized yet.' This is misleading for users who genuinely didn't browse. More importantly, the condition also fires when the browser bucket exists but the query returned zero duration because the user was AFK the entire period or because the browser events were filtered out by AFK filtering (filter_period_intersect with not_afk). In those cases, the browser watcher may have recorded events, but they were removed by the AFK filter, so the hint incorrectly suggests a fork recognition problem. The mechanism: isBrowserAllowlistMiss() only checks duration and top_domains length, not whether any browser events were recorded before AFK filtering. The observable consequence is a false-positive hint shown to users who didn't browse or whose browsing was filtered as AFK, which is a user-facing correctness bug in the new UI feature.

_{How this was verified: Checked the activity store's browser data shape: duration is sum_durations(browser_events) after filter_period_intersect with not_afk, so AFK-filtered browsing yields duration 0. The hint is shown for all browser visualizations when this condition is true.}

_{Consensus: 2/2 passes agreed}
Distinct keys: 1 (general)

Previous review passes

commit	score	findings	engine	when
06d1d87d080e	4/5	1	agent	2026-09-16 09:08 UTC
42b01322a91a	3/5	1	llm	2026-09-16 12:02 UTC

_{Reviewed 420d0bde37b8 · openrouter/deepseek/deepseek-v4-flash-0731 · llm (in-band) engine · 220s · about this reviewer}

_{Maintainer commands}

_{@TimeToBuildBob review (own line) — fresh review · @TimeToBuildBob fix — a worker acts on the findings. Once per comment; 👀 = received.}