Webapps: make browser selection configurable (webapp-level default + per-app override)

[alebak]

The problem is one line

omarchy-launch-webapp decides which browser runs every webapp in a single hardcoded step:

browser=$(xdg-settings get default-web-browser)

case $browser in
google-chrome* | brave* | microsoft-edge* | opera* | vivaldi* | helium*) ;;
*) browser="chromium.desktop" ;;
esac

exec setsid uwsm-app -- $(sed -n 's/^Exec=\([^ ]*\).*/\1/p' ... ) --app="$1" "${@:2}"

There is no way to influence this. Not per install, not per app, not globally. Your webapp browser is your system browser, or it is Chromium.

What people already do about it

Discussion #2468 — "Using Firefox as the WebApp Browser in Omarchy" — has 38 upvotes and 22 comments, and it is a tutorial for editing omarchy-launch-webapp by hand.

That thread is the evidence. Users are not asking for a feature in the abstract; they are patching a shipped script, and paying for it on every update:

Did the same but in a separate launch command so updates don't screw me over

Parallel copies of a core script, maintained by hand, because there is no extension point. That is the actual cost of the missing setting.

Proposal: three levels, each falling back to the one above

1. System default — xdg-settings get default-web-browser. Exists today, stays the default.

2. Webapp default — one setting that says "webapps use browser X", independent of the system browser. This is the level that is missing entirely, and the one that covers most of #2468: keep Firefox as your everyday browser, run webapps in Chromium — or the reverse.

3. Per-app override — the browser is a property of the individual webapp, chosen at install time and stored in its .desktop.

Level 3 is not speculative. Linux Mint's WebApp Manager has shipped it for years: each generated .desktop carries an X-WebApp-Browser field, and the Exec line invokes that browser directly. You pick the browser per app in the UI, next to the name and the icon.

Concretely, that lets a user run WhatsApp in Brave, Claude in Chromium, and ChatGPT in Chrome — separate browsers, separate extension sets, separate managed policies — without touching the system default.

This overlaps PR #4749 and should be designed with it

PR #4749 (--isolate, from discussion #6250) adds --user-data-dir= to the same exec line to give a webapp its own process tree.

Both changes edit the same two lines, and they interact: profile flags are browser-specific. Chromium-family browsers take --profile-directory / --user-data-dir; Firefox takes -P. Today --profile-directory=Default sits in the .desktop Exec, which silently assumes the browser will always be Chromium-family — an assumption that stops holding the moment the browser becomes selectable.

So the underlying fix for both is the same: omarchy-launch-webapp currently resolves browser, profile and flags inline, with no seam. Give it a per-browser launch adapter — one that knows how each family expresses "this URL, in its own window, with this profile" — and --isolate and browser selection both become small changes on top of it instead of two patches fighting over the same line.

Caveat, stated up front

Firefox has no --app mode. It works as a webapp browser through a different path — dedicated profile via -P, --new-window, --class, plus userChrome.css to hide the UI — which is exactly what #2468 documents. Any per-app browser support has to treat "how do I launch a bare window for this URL" as per-browser behavior, not a shared flag string. That is an argument for the adapter, not against the feature.

Threads this would consolidate

• Using Firefox as the WebApp Browser in Omarchy - Solution / Tutorial #2468 — Firefox as the webapp browser (Ideas, ▲38) — currently solved by hand-patching
• Current webapp implementation sucks and PR 2121 should be revisited #4035 — asks for the same root fix from the Firefox side
• any browser in webapp bindings #2121 — closed, unmerged; attempted level 1 only
• Using Zen Browser with webapps #1972 — Zen Browser with webapps
• Any way to support Brave profile with omarchy-open-browser #1681 — Brave profile support
• Webapp default browser #1987 — "Webapp default browser" (Q&A, still unanswered) — opens by linking to line 6 of this very script
• Webapp crash takes down all browser windows — add process isolation option #6250 / Add --isolate option for webapps to run in separate browser process #4749 — isolation, same lines of code

Six threads over more than a year, all landing on the same hardcoded browser lookup. Worth fixing as one seam rather than six special cases.

[hierophantos]

Strong +1, and a data point on the failure mode that I think strengthens the case.

There's a sharper edge than "your webapp browser is your system browser or Chromium": if your default is outside the allowed list and chromium.desktop isn't present, web apps don't fall back to anything — they fail silently.

The sed finds no file, the command substitution comes back empty, and the line becomes:

exec setsid uwsm-app -- --app="https://my-app.com"

--app=… gets run as the program name. No error, no notification, nothing in the journal pointing at the browser. Web apps just stop opening. I hit this with LibreWolf as my default and Brave installed but no Chromium — Brave was sitting right there, unused, because the fallback is by name rather than by what's installed. It took reading the script to work out why.

A lighter workaround than editing the script

For anyone landing here from #2468: you don't have to patch omarchy-launch-webapp or maintain a parallel copy. The lookup checks ~/.local before /usr:

sed -n 's/^Exec=\([^ ]*\).*/\1/p' {~/.local,~/.nix-profile,/usr}/share/applications/$browser

So a user-level shim at the fallback name wins, and nothing shipped gets touched:

# ~/.local/share/applications/chromium.desktop
[Desktop Entry]
Type=Application
Name=Chromium (shim to Brave)
Exec=/usr/bin/brave
NoDisplay=true

LibreWolf stays the default browser for links, web apps run in Brave with --app= intact (each keeps its own window class and icon), and it survives omarchy update. It's still a shim — a file called chromium.desktop that launches Brave is going to confuse someone later — but it beats forking a shipped script.

That's really an argument for level 2 in your proposal: the reason people reach for these hacks is that there's no supported way to say "web apps use browser X." Even without the per-app override, a webapp-level default would remove the need for all of it.

_{Written with the help of Claude Code; the trace and shim are from my own machine.}