Open links in a specific Chromium profile

[matijazezelj]

Stacks on #63 and #64. Only the last four commits are new — the rest are those PRs. Happy to rebase once they land, or to split this differently.

Lets a link open in a specific Chromium profile, both from the picker and from a rule.

Today a browser is identified only by its .app bundle URL — browsers: [URL], Rule.app: URL, App.app: URL — so a browser with several profiles can only appear once, and a rule can say "open in Chrome" but never which Chrome.

What it looks like

A browser with two or more profiles is represented by its profiles instead of by itself:

  Firefox
  Chrome — Work          ← own shortcut, own hide toggle, own row
  Chrome — Personal
  Brave                  ← one profile, unchanged

Opening the plain row would just be a fourth row that does nothing distinct, so it is replaced rather than kept alongside. Single-profile browsers are untouched, and the rows carry the profile's picture as a badge on the browser icon so they stay distinguishable at a glance.

Rules and site mappings now pick from that same list rather than opening a file dialog over every application on the machine, which also means a profile needs no second control. "Other Application…" is still there for apps that are not registered browsers.

Discovery

Profiles come from the browser's own user data directory, located by reading CrProductDirName from its Info.plist and falling back to a small table of known bundle identifiers. Brave ships that key, stable Chrome does not.

Anything that yields neither is simply not a Chromium browser — so Safari and Firefox are excluded with no special-casing, and unlisted forks and beta channels work without being added here. Discovery is driven by installed apps rather than by the presence of a data directory, because those outlive uninstallation and would otherwise invent browsers that are not there.

The part worth knowing about: macOS blocks the read

macOS refuses to let one app read another's data under ~/Library/Application Support. Local State comes back as Operation not permitted, and contentsOfDirectory on the profile folder fails too.

This is invisible from a terminal-launched build, which inherits the terminal's permissions — it only appears once the app runs under its own identity. Two traps I walked into:

• FileManager.isReadableFile returns true while the read still fails. It stats rather than opens.
• fileExists on a profile subdirectory also returns true. Only opening is refused.

So there is a per-browser grant: an "Enable profiles" button opens a folder picker at the browser's data directory, and the security-scoped bookmark from that choice carries the permission across launches. Reads run inside that scope, avatars included. The button shows only for a Chromium browser whose profiles could not be read, so it disappears once granted and never appears for Safari or Firefox. Without a grant the read is still attempted, since a browser that does not protect its data works unaided.

If you would rather not have a permission prompt at all, the fallback is probing fileExists for Default / Profile N, which works with no permission but yields directory names instead of the names the user chose. Happy to switch if you prefer that.

Migration

browsers and hiddenBrowsers were arrays of bare URL strings, and Array+RawRepresentable turns any decode failure into an empty default with nothing shown — so a naive type change would silently wipe the user's browser order and hidden set. BrowserTarget therefore decodes both the old bare-string shape and the new one, and I verified that against a real installed configuration before changing anything.

Shortcuts keep the bare bundle identifier when there is no profile, so existing ones still resolve. The private argument stays keyed by bundle identifier and lives on the plain row, because incognito belongs to the browser rather than to one profile.

One asymmetry worth documenting: rules and apps stay readable by older builds, since the new profile key is omitted when nil. browsers does not — an older build fails to decode the object form and empties the list, requiring a rescan.

Fixes met on the way

• The ordering comparator returned true when neither entry had a known position, so a < b and b < a were both true. That is not a strict weak ordering and left sort() undefined. Replaced with a stable merge that keeps the user's arrangement, puts profiles where the plain row used to sit, and is idempotent — which is what makes it safe for the Browsers tab to refresh on appear instead of only on an explicit rescan.
• A link was silently discarded when incognito was requested but no private argument was configured: the if was skipped yet the URLs were still replaced with [].
• The keyboard cursor could select rows that render nothing, because the counts included entries whose bundle no longer resolves while the rendering skipped them.
• An unrecognised --profile-directory makes Chromium create a fresh empty profile, so a stale one is dropped and the browser launched normally rather than littering its profile list.

Verification

Compiles with 0 errors and 0 warnings in Swift 6 against the macOS 26.5 SDK targeting macOS 14.0. Beyond that:

• Forwarded --profile-directory was confirmed to reach an already-running browser through Chromium's process singleton — the whole feature rests on that, so it was tested before anything was written.
• Migration was checked against a real installed configuration: existing browsers, hidden entries and rules all survive.
• Ordering was checked for expansion, upgrade placement, idempotence, and preservation of a manual reorder.
• The resulting build has been running as my default browser on macOS 27, with profile rows, badges, a granted browser, and rules targeting a named profile.

Disclosure

Written with AI assistance (Claude Code), same as #63 and #64. Everything above was compiled and exercised in a running build before submitting. This is a large and fairly opinionated change, so treat it as a proposal — I am happy to cut it down, split it, or change any of the choices called out above.