fix(launcher): find Flatpak web-app shortcuts, and give them the right profile - #88
Merged
Conversation
…t profile The first pass at this missed every shortcut it was meant to fix on a Flatpak engine, which is the common Linux install. Three bugs, found by looking at a machine where it had changed nothing: Shortcuts were matched by filename prefix `chrome-`. That is what Chromium names its own, but a Flatpak exports web apps to the host through flextop, as `<flatpak-app-id>.flextop.chrome-<app-id>-<profile>.desktop`. Eleven shortcuts on the reporting machine were invisible to the scan. What makes a file a web-app shortcut is `--app-id` on its Exec line, so ask that instead of the name. Ownership was decided by `--user-data-dir` matching a TronBrowser profile. A flextop export carries no `--user-data-dir` at all, so every Flatpak web app read as "somebody else's" and was skipped. The profile itself records what it has installed, under `Web Applications/Manifest Resources/<app-id>`, and that answer does not depend on what the engine chose to write. Either rule now establishes ownership; matching neither still means hands off. That missing `--user-data-dir` is also the failure the user sees. Without it the shortcut opens the Flatpak's OWN default profile, where the app is not installed -- so the browser starts, finds nothing and exits a few seconds later. It reads as a crash but it is the right browser opening the wrong profile. Sync now fills in the profile the app is actually installed in. Switches are carried over by allowlist rather than "everything after the program", because the program is not always the engine: a flextop Exec is `flatpak run --branch=… --command=… <app-id>`, and forwarding those tokens would hand the `tron` CLI a bare `run`, which is one of its own subcommands. Since that deliberately drops tokens, revert can no longer rebuild the line -- it restored `/usr/bin/flatpak` with no `run --command=…` and left a shortcut that launched nothing. Each original Exec is now recorded verbatim and restored as-is; shortcuts patched by 3.9.9 still revert via the old reconstruction. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SZXtxiVkXd7rFmvrMYV7Ut
ThreatCrush Security Scan49 finding(s) MEDIUM: 31 | LOW: 18
Snippets are redacted; ThreatCrush never prints matched credential material. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #87, which missed every shortcut it was meant to fix on a Flatpak
engine — the common Linux install. Found by looking at a machine where it had
changed nothing.
What was actually wrong
1. Shortcuts were matched by the filename prefix
chrome-. That is whatChromium names its own, but a Flatpak exports web apps to the host through
flextop:
Eleven shortcuts on the reporting machine were invisible to the scan. What makes
a file a web-app shortcut is
--app-idon its Exec line, so ask that.2. Ownership was decided by
--user-data-dir. A flextop export carries none,so every Flatpak web app read as another browser's and was skipped. The profile
records what it has installed, under
Web Applications/Manifest Resources/<app-id>,and that does not depend on what the engine wrote. Either rule now establishes
ownership; matching neither still means hands off.
3. That missing
--user-data-diris the bug the user sees. Without it theshortcut opens the Flatpak's own default profile, where the app is not
installed — so the browser starts, finds nothing, and exits a few seconds later.
It reads as a crash, but it is the right browser opening the wrong profile. Sync
now fills in the profile the app is actually installed in.
Two things that fell out of fixing it
Switches are now carried over by allowlist rather than "everything after the
program", because the program is not always the engine. A flextop Exec is
flatpak run --branch=… --command=… <app-id>, and forwarding those tokens wouldhand the
tronCLI a barerun— one of its own subcommands.Since that deliberately drops tokens, revert could no longer rebuild the line:
it restored
/usr/bin/flatpakwith norun --command=…, leaving a shortcut thatlaunched nothing. Each original Exec is now recorded verbatim and restored as-is.
Shortcuts patched by 3.9.9 still revert through the old reconstruction path.
Tests
6 new cases reproducing the real machine — flextop filename,
flatpak runExec,no
--user-data-dir, app present in the profile, plus a stray snap Chromiumshortcut that must stay byte-identical. 20 in the file, 109 in the desktop suite.
Typecheck and lint clean.
🤖 Generated with Claude Code
https://claude.ai/code/session_01SZXtxiVkXd7rFmvrMYV7Ut