Skip to content

feat(browser): support Chrome channels and Chromium profiles - #614

Open
ciltocruz wants to merge 4 commits into
nesszer:mainfrom
ciltocruz:feat/chrome-browser-channels
Open

ciltocruz wants to merge 4 commits into
nesszer:mainfrom
ciltocruz:feat/chrome-browser-channels

Conversation

@ciltocruz

@ciltocruz ciltocruz commented Sep 24, 2026 •

Copy link
Copy Markdown

Summary

Not everyone uses the stable Chrome release, so I thought it would be useful to support the other Chrome channels too.

  • Adds Chrome Beta, Chrome Dev, Chrome Canary, Chrome for Testing, and Chromium as separate cookie-import sources.
  • Keeps the existing Chrome and Microsoft Edge behavior.
  • Supports the requested Windows profile roots, including discovery from WSL paths.

Related issue

Fixes #613

Affected areas

  • Settings UI
  • Documentation
  • Other: browser profile discovery

Validation

  • cargo fmt --all -- --check
  • git diff --check b585d4887499c6b62d3a9ce7c22444e4bd283961...HEAD
  • Focused Rust test could not run in this Linux environment: compilation stops in unrelated rust/src/providers/muse/local_usage/cache.rs because it uses Windows-only APIs.
  • Thermo-nuclear code quality review completed; its duplicate browser registry finding was addressed.
  • Contributor-reported Windows manual smoke test: the app showed Chrome and its profiles in the cookie-import browser list.

UI / tray proof

  • Not applicable
  • CUA Driver visual proof attached
  • CUA Driver was unavailable from this WSL session; equivalent manual check: the contributor launched the Windows app and confirmed Chrome and its profiles appeared in the browser list.

Notes for reviewers

Please review that all six requested User Data roots map to distinct browser choices, while existing Chrome and Edge behavior remains unchanged.

Summary by CodeRabbit

  • New Features
    • Browser import now detects Chrome Beta, Dev, Canary, and Chrome for Testing as separate options, with distinct profiles on supported Windows environments, including WSL.
  • Documentation
    • Updated browser import guides to list Chrome Stable, Beta, Dev, Canary, Chrome for Testing, and Chromium alongside Edge, Brave, and Firefox.

@coderabbitai

coderabbitai Bot commented Sep 24, 2026 •

Copy link
Copy Markdown

Review in Change Stack →

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: c8e6b287-a62f-4ec4-b4d0-b2ad9425af2b

📥 Commits

Reviewing files that changed from the base of the PR and between cb68c7d and 4fd971b.

📒 Files selected for processing (3)
  • apps/desktop-tauri/src-tauri/src/commands/browser_import.rs
  • rust/src/browser/detection.rs
  • rust/src/browser/wsl_paths.rs

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.


📝 Walkthrough

Walkthrough

The change adds Chrome Beta, Dev, Canary, Chrome for Testing, and Chromium as distinct browser import sources. It centralizes browser profile path resolution, updates WSL detection to use the shared detector, and updates browser import keys and documentation.

Changes

Browser Import Sources

Layer / File(s) Summary
Browser types and profile paths
rust/src/browser/detection.rs
Adds four Chrome channel variants, stable keys, display names, and profile-root mappings. Shared detection resolves browser paths from Local and optional Roaming roots. Tests cover browser keys, names, membership, and profile roots.
WSL browser detection
rust/src/browser/wsl_paths.rs
Delegates WSL browser and profile discovery to the shared detector. Tests cover Chrome Beta profile discovery and Firefox profiles under the Roaming root.
Import keys and browser lists
apps/desktop-tauri/src-tauri/src/commands/browser_import.rs, README.md, docs/PROVIDERS.md
Uses BrowserType::key() for browser listing and lookup. Updates browser lists to distinguish Chrome channels and Chromium.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant WslBrowserDetector
  participant BrowserDetector
  participant BrowserType
  WslBrowserDetector->>BrowserDetector: Call detect_in_roots with Local and optional Roaming roots
  BrowserDetector->>BrowserType: Resolve each browser path with user_data_dir
  BrowserDetector-->>WslBrowserDetector: Return detected browsers and profiles
Loading

Suggested reviewers: finesssee

Merge Risk: ⚪ Minimal · up to 4fd97

The new browser sources remain distinct and selectable, with imports reading their own profiles. No identified issue blocks merging after normal checks.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 4fd97

Cookie import can now read additional Chrome profiles, including Windows profiles visible from WSL. Selection remains limited to detected browsers and provider-specific cookies. A pre-existing failure-path cleanup weakness can affect the newly supported profiles, but no new boundary bypass was established.

Retained concerns

  • Low · security · inferred: Failed extraction can leave a temporary copy of a cookie database. The cleanup gap predates this PR, but the newly selectable Chrome-channel profiles expand the assets that can encounter it; exposure of a leftover copy depends on local file permissions.
Security review details

Security Blast Radius

  • inferred — The added sources expand local cookie-reading reach to the detected Chrome-channel profiles, including Windows roots visible in WSL; the import caller cannot supply an arbitrary root.

Security Findings and Attack Paths

  • inferred — An extraction error after the database copy can leave that copy in the system temporary directory. This is an existing failure path newly reachable for the added profiles; whether another actor could read a leftover file is unestablished.

Trust Boundaries and Controls

  • observed — The desktop command resolves a supported provider and detected browser before extraction, filters cookies for the provider domain, and validates the header before persistence.

Resilience and Maintainability Implications

  • observed — Extraction tolerates individual profile failures and removes the temporary database on normal completion; an empty result does not reach cookie persistence.

Hardening Proposals

  • proposed — Use failure-safe temporary-file cleanup for copied cookie databases and verify its behavior and permissions on Windows and WSL.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly and concisely describes the main change: adding support for Chrome channels and Chromium browser profiles.
Linked Issues check ✅ Passed PR #614 meets the coding requirements in issue #613. BrowserType adds separate Chrome Beta, Chrome Dev, Chrome Canary, and Chrome for Testing variants. The shared path mapping includes all requested…
Out of Scope Changes check ✅ Passed The changes stay within issue #613. Browser model updates, shared Windows and WSL discovery, IPC key handling, tests, and documentation support separate Chrome channel and Chromium cookie-import sourc…
Docstring Coverage ✅ Passed Docstring coverage is 93.75% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 16 functions across 3 files.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@Finesssee

Copy link
Copy Markdown
Collaborator

Thanks for the PR, I will review it ASAP.

@ciltocruz

Copy link
Copy Markdown
Author

Thanks!

@Finesssee

Copy link
Copy Markdown
Collaborator

Thermo-nuclear code-quality review

Verdict: FINDINGS. Reviewed head cb68c7db3. Thanks for the port. The channel paths look right; the findings below are about structure.

P1: user_data_dir_under is a partial table, so every call site still hand-rolls the rest

The new BrowserType::user_data_dir_under (rust/src/browser/detection.rs:69) covers only the Chrome channels and Chromium. It returns None for Edge, Brave, Arc and Firefox. Because the table is partial, all three consumers still carry their own path lists:

  • get_user_data_dir, WSL branch (detection.rs:~195): a six-variant or-pattern that delegates, plus hand-written Edge, Brave and Arc paths.
  • get_user_data_dir, native branch: the same or-pattern, then .expect("matched a Chromium browser") (detection.rs:235). That panic is only safe because of the match arm directly above it.
  • WslBrowserDetector::detect_all (wsl_paths.rs:33): calls windows_browser_candidates, then .chains a second hardcoded Edge, Brave and Arc list. The helper's doc comment has to explain which browsers it skips.

Suggested restructure: make the table total. BrowserType::user_data_dir(local: &Path, roaming: &Path) -> PathBuf covers every variant, Firefox included, via roaming. Then:

  • both get_user_data_dir branches become a single call each, so the or-patterns and the expect go away;
  • windows_browser_candidates and the .chain(...) go away, and the WSL detector just iterates BrowserType::all();
  • the two new tests, which currently check the same mapping twice, collapse into one table test.

That leaves one path table and no panic, and the next browser to be added only needs its own match arm.

P2: The WSL detector is a second copy of BrowserDetector::detect

wsl_paths.rs:108 has its own detect_chromium_profiles, which duplicates detection.rs:261. Once the path table is total, WSL detection is BrowserDetector::detect with a different root, so it can reuse the same code instead of keeping a parallel copy. This is pre-existing, but this PR widens the gap by adding five more browsers to both paths.

P3: The stable IPC key belongs on BrowserType

browser_type_key (apps/desktop-tauri/src-tauri/src/commands/browser_import.rs:91) is a shell-side mapping, and this PR adds four more strings to it. display_name already lives on BrowserType. Put key() next to it so the canonical crate owns both, and so CLI and shell can't drift.

@ciltocruz

Copy link
Copy Markdown
Author

Thanks for the detailed review. I pushed 4fd971b to address all three points:

  • BrowserType now owns the complete AppData path mapping (including Firefox under Roaming), and both native and WSL detection use it.
  • WSL browser discovery now reuses BrowserDetector profile detection rather than maintaining separate Chromium/Firefox scanners.
  • BrowserType::key() now owns the stable IPC keys used by browser import.

cargo fmt --all -- --check and git diff --check passed. An isolated harness compiling the current browser modules passed 5 tests. The full Rust crate tests cannot start on Linux because unrelated Muse cache code uses Windows-only APIs; native Windows and UI validation are still pending.

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

Successfully merging this pull request may close these issues.

[Feature]: Support Chrome channels and Chromium profiles

2 participants