Every AppImage came out as "cannot tell" because the payload is a
compressed filesystem and none of the Chromium markers is on disk to be
found. The names are reachable, though: squashfs keeps the name of
everything it holds in one table of a few kilobytes, and a name is all
this question needs. That table is now read and inflated in place -
nothing is unpacked, and the image is never run, which a scan started by
the path unit has no business doing anyway.
So a Tauri AppImage such as Modrinth is recognised as WebKitGTK and
dropped from the list instead of being offered as something that could be
switched on - there is no autoscroll in WebKit to ask for - and an
Electron one is covered like any other application.
Left as "cannot tell": lzo and lz4, which squashfs stores as bare blocks
no tool will read without their own framing, and the original ISO9660
layout.
Alongside:
- The detect cache carries a format line. Its entries are keyed on size
and mtime, so an AppImage that has not changed would otherwise keep
answering the way an older version decided it did, forever.
- A marker list for whole-tree searches, which is what a Flatpak, a snap
and an AppImage need. icudtl.dat, snapshot_blob.bin and resources.pak
are out of it: Flutter ships an icudtl.dat in data/, and next to a
binary those names are evidence while four directories down they are
not. The Flatpak and snap searches now share that list.
Inside a Chromium application the flag settles this on its own - with
autoscroll on, Blink stops pasting the primary selection. Everywhere else
on the desktop middle click goes on pasting, which is the thing this whole
program exists to get away from.
KWin has a switch for it, on Wayland, where the paste is a protocol the
compositor either offers or does not: EnablePrimarySelection in kwinrc.
Written with kwriteconfig, the way System Settings would, because kwinrc
has a cascade behind it. What the key said before goes in the ledger, so
disable puts it back - and a key that already said false is left alone and
not recorded, so a paste the user switched off themselves is never
switched back on.
X11 has no such switch and nothing is written there.
The patch that keeps the script's length was the good path and appending was
the fallback, with -noverifyfiles on everything that starts Steam to cover for
it. That cover does not exist.
Steam checks its files at the shutdown it runs itself, not only at a start
somebody handed arguments to, and that run carries no -noverifyfiles whatever
the session was started with. One wrong length there costs the whole client
package downloaded, extracted and installed again - and the client quits at the
end of it instead of coming up, which is the "Steam just closed itself" that
this was seen as:
BVerifyInstalledFiles: steamwebhelper.sh is 130 bytes, expected 84
Update wird heruntergeladen ... Paket wird extrahiert ...
Aktualisierung abgeschlossen, Steam wird geladen ... Shutdown
So the flag now either fits in the space the comments give back or it is not
written at all, and the status screen says Steam is not patched. No autoscroll
in the interface is a far smaller thing than a client that reinstalls itself.
With no growing patch left to prop up, -noverifyfiles has nothing to do and is
gone with everything that carried it: Steam's launcher entry, its autostart
entry, the shortcuts on the desktop and the ones it writes for single games.
Steam repairs its own installation again. An installation from an older version
is taken back once through the flag scheme, and a patch that version appended
is rebuilt to fit at the next apply - or taken back, if the comments cannot pay
for it.
--enable-blink-features is on the list of flags Chromium warns about, so every
browser the flag was applied to put a yellow "unsupported command-line flag"
bar above each page.
Browsers are given --enable-features=MiddleClickAutoscroll instead. It asks for
the same thing - Blink generates a feature of the same name for each of its
runtime flags - and is not on that list. That spelling only works from Chromium
124 onwards, so everything else keeps the flag that works everywhere: an
application embedding an older Chromium, Steam's CEF among them, has no such
bar to show anyway.
Helium knows the feature under a name of its own and ignores the Chromium one,
so browsers are asked for HeliumMiddleClickAutoscroll as well; autoscroll never
worked there before. A name a browser does not know is ignored, which is what
makes one list safe for all of them.
An installation set up by an earlier version is taken back and written again
once, because a file that is already marked as patched would otherwise be left
alone with the old flag in it.
Steam's autoscroll worked, except when it didn't. Every report of that came
down to the same thing: Steam started in a way that carried no -noverifyfiles,
noticed the patched web helper script, put its own copy back, and spent the
session without the flag. There is no way to make every possible way of
starting Steam carry an argument - a game launcher, a shortcut, a terminal,
another program calling `steam steam://` - so the patch stops depending on it.
The check is on size and timestamp, not on content, so the patch is now written
to look untouched: the bytes the flag costs come back out of the script's own
comments, and the timestamp of the untouched copy is restored afterwards. The
file Steam finds is exactly as long and exactly as old as the one it wrote. A
client that verifies its files finds nothing to repair. -noverifyfiles stays as
the fallback for a script with no comments left to pay for the flag.
Two things fall out of that. A patch that keeps the size no longer has to wait
for Steam to close, because there is no size mismatch for the client to chase;
only the growing one still defers. And an installation patched by the earlier
version is quietly redone at the original size on the next apply, so the fix
arrives without anyone having to know about it.
Then the launch paths that were never covered:
- Shortcuts on the desktop itself. Nothing in the XDG search path looks at
that folder, so nothing had ever seen them - and Steam writes one there for
every game somebody asks for a shortcut to. Its name is translated, so it is
read from user-dirs.dirs and handed to the watcher in a drop-in.
- Steam as a Flatpak was never recognised as Steam, so its entry got nothing
while its script got patched - the worst of both. The switch goes after the
application id there, where flatpak passes it on rather than reading it.
- steam-native and steam-jupiter, which are ordinary Steam starts under
another name, and Flatpak and snap entries in ~/.config/autostart.
Two things found on the way: a client update left the undo copy holding the
script from before the update, so undoing would have put an old version back;
and a shortcut edited in place and later deleted would have been recreated by
`disable`.
The README asked for "Arch or an Arch derivative" and the code had two
reasons for it. Neither of them was the mechanism, which is why this is
mostly a matter of not assuming.
The first was the flag file. Arch wraps Electron and Chromium in launchers
that read $XDG_CONFIG_HOME/<name>-flags.conf, and that route is the good
one - it survives upgrades and applies to a launch from a terminal. Debian,
Ubuntu, Fedora and openSUSE keep the equivalent under /etc, where it is the
system's file and not the user's, so there is nothing to write and those
applications have to go through their desktop entry instead. That already
worked, because a launcher is read rather than assumed - but only if the
launcher was recognised as Chromium at all, and it was not:
APPNAME=chromium
LIBDIR=/usr/lib/chromium
exec -a "$APPNAME" "$LIBDIR/$APPNAME" $CHROMIUM_FLAGS "$@"
is the shape every one of those wrappers has, and following it needs the
assignments above resolved and -a understood as renaming the process rather
than naming the program. Both are done now, and the wrappers that still
cannot be followed are caught by CHROMIUM_FLAGS and CHROME_WRAPPER, which
nothing but a Chromium launcher sets. Two applications on the machine this
was written on turn out to have been missed for the same reason: Helium,
whose wrapper is followed to a payload full of markers, and ONLYOFFICE,
which ships libcef.so.
Resolving more wrappers made an old inference dangerous. Any launcher that
could be followed also had "<target>-flags.conf" invented for it, on the
theory that a wrapper builds that name from a variable at runtime. For an
application that simply execs its own binary that file is read by nobody:
the flag would have gone to ~/.config/DesktopEditors-flags.conf and the
desktop entry that would have worked was skipped. The name is now derived
only once the target has shown it reads a flag file at all.
The second reason was snaps. /snap/bin/<name> is a symlink to snapd, so
following it lands on /usr/bin/snap and says nothing; the payload is in the
mounted revision, and that tree takes the same marker check as anything
else. They get a settings switch of their own next to Flatpak, and the
launcher entry as their only way in.
Packaging is now a gate in front of the category rather than a category
beside it. A Chromium installed as a snap or a Flatpak was filed as neither
an application nor a browser, so turning browsers off did not reach it -
which on Ubuntu means the default browser. It is a browser that happens to
be packaged as a snap, and both switches apply.
The rest is the same not-assuming: Steam is found in Debian's
~/.steam/debian-installation and in the snap's private tree, the Flatpak
and snap export directories are scanned even when a session started before
they were installed left them out of XDG_DATA_DIRS, /usr/lib/x86_64-linux-gnu
counts as a shared directory the way /usr/lib does, the watcher covers
snapd's export directory and the NixOS and Guix profiles, LANG is read from
/etc/default/locale as well as /etc/locale.conf, and the systemd user unit
directory is asked of systemd instead of guessed - while still following a
PREFIX that was asked for.
Steam writes a desktop entry for every game somebody asks for a shortcut
to, and it starts the same program the client's own entry does:
Exec=steam steam://rungameid/3527290
The scan only ever looked at the first token, found steam there, and filed
the game under the same kind as the client. So PEAK sat in the applications
list reading "on (Steam)", counted towards the applications covered, and
offered a space bar to switch it off again - as though it were something
this program had anything to offer. It is not: a game is whatever engine it
was built with, and none of them reads a Chromium argument.
An entry carrying a steam:// address of its own is not a program, it is one
more way of starting Steam. The client's own entry never has one - it takes
an address from the outside, through %U - and that is what tells the two
apart. Those entries go to the Steam module now instead of into the list.
They keep -noverifyfiles, for the same reason the rest of the Steam handling
has it: starting a game with the client closed is a Steam start like any
other, and without the switch it finds the patched web helper script, puts
its own copy back, and the interface loses autoscroll for the rest of the
session.
Steam compares its installed files against its manifest at every start and
restores whatever differs, which is why its launcher entry carries
-noverifyfiles. The entry in ~/.config/autostart never got it: it points at
/usr/bin/steam, a shell script, so it fell through the Chromium filter in
mca_autostart_apply and was left alone.
A Steam started at login therefore verified, found the web helper script 46
bytes larger than the manifest says, restored it, and the path unit patched
it straight back - an update dialog that begins again every few seconds and
never finishes. The same client started from the menu was fine, which is
what made it look like a problem of Steam's own.
The autostart entry now carries the switch as well. It follows the Steam
setting rather than the autostart one, because leaving it out while Steam is
patched is exactly what causes the loop.
That covers the entry that exists; a terminal or a script still starts Steam
without the switch. So the patch no longer fights back either: a script that
was patched before, is not patched now, and belongs to a client that is
still running has just been restored by Steam, and doing it again would only
have the two of them undoing each other. It waits for the next apply with
Steam closed - the helper is started once, at the start, so patching it now
would not have helped that session anyway.
Also: Steam does not checksum that script, it compares sizes - the log says
"Verifying file sizes only" - while the comments and the documentation
claimed otherwise. And the status screen now tells a patch that is waiting
from one that is missing, instead of reporting both as not patched yet.
"Apply now" had nothing to do in the normal case. Enabling applies, the
watcher handles everything installed afterwards, and the settings and
applications screens apply on their way out - so pressing it answered
"already applied to 14 applications" and that was the whole interaction.
It is now "Re-apply everything": the state is taken back and written again
from scratch. That is the answer to the question the status block can raise
but nothing could act on - Steam showing as not patched after a client
update, an application that drifted, a flag file edited by hand.
Uninstalling an application used to leave the entry shadowing it behind, in
the user home where the package manager cannot see it, offering to start a
program that is gone. A plain apply only looks at what exists now, so the
watcher never noticed either. Those are removed on every apply now, not just
when rebuilding.
A list of names reads like a compatibility list, invites the question of
whether the one you care about is on it, and is out of date the moment
something new turns up. The point is that there is no list: every launcher
is examined and the Chromium-based ones are identified by what they ship.
A desktop entry that already lives in ~/.local/share/applications is the
user's own file, patched in place with the original kept aside. It used to
get the same X-MCA-Generated marker as a shadow copy, which made the next
scan skip it, fall back to the system entry, and overwrite the user's file
with a shadow - and then delete it on revert instead of restoring it.
The two cases now carry different markers. Only a shadow is skipped by the
scan and deleted when undoing; an entry patched in place stays in the scan
and is restored from its backup.
Also: resolve the applications screen's labels once instead of per row per
keypress, and drop code nothing calls.
Middle-click autoscroll for every Chromium-based application on the system:
Electron and CEF applications, Chromium-based browsers, Flatpaks, Spotify and
Steam, plus anything installed later.
The flag goes into an Arch wrapper's <name>-flags.conf where one exists, and
into a shadowing desktop entry where it does not. Steam gets its web helper
script patched and -noverifyfiles on its launcher, because it restores its own
files otherwise. Every change is recorded so it can be taken back exactly.
Felitendo