Discord's entry is `discord --url -- %u`. The flag went in before the
field code, which put it after the double dash, and that is where
Chromium stops reading switches and starts treating everything as an
address. The feature never came on.
Discord no longer ships its application. /usr/bin/discord is a few lines
of shell that run updater_bootstrap, which downloads Electron into the
user's config directory on first start and execs it from there. So there
is no binary next to the launcher to find markers around, and the path it
hands over to is built out of $HOME and the version it just downloaded,
which the script reader cannot resolve. Discord came out as "not
Chromium" and was dropped from the list entirely.
The name of the bootstrap it ships is the one thing left that says
Discord, so that is the hint now.
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.
KDE's own middle-click paste is turned off along with everything else. Inside a
Chromium application the flag already settles it - with autoscroll on, Blink
stops pasting the primary selection - but everywhere else on the desktop middle
click goes on pasting, which is the thing this program exists to get away from.
KWin has a switch for it on a Wayland session, where the paste is a protocol
the compositor either offers or does not, and that is what gets written. It is
true from the next login on. What the key said before is recorded, so disable
puts it back, and a key that already said no is left alone and never switched
back on. X11 has no such switch and nothing is written there.
Off under Settings for anyone who wants the paste kept.
A build with a prefix of its own put them in $(PREFIX)/lib/systemd/user, which
is right for /usr/local and wrong for the one prefix an install without root
can use: systemd searches $XDG_DATA_HOME/systemd/user and never
~/.local/lib/systemd/user. An install into ~/.local came out with a working
program whose watcher could not be enabled at all.
They go under share now, which both a system prefix and a home one are
searched for. Nothing changes for the packages - the deb and the rpm pass
USERUNITDIR in themselves.
That prefix is what an atomic distribution leaves a user, so the readme says
how to install on Bazzite: layer the rpm and reboot, or put the whole thing in
$HOME, which is where everything it writes ends up anyway.
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.
Steam's helper script is only patched when the patch keeps the file at the
length Steam wrote down. Where the comments cannot pay for the argument,
nothing is written at all: a file of the wrong length costs the whole client
package downloaded and installed again, and a client that quits at the end of
it instead of coming up.
With no such patch left to prop up, -noverifyfiles is gone from everything that
carried it - Steam's launcher entry, its autostart entry, the shortcut on the
desktop and the ones Steam writes for single games. Steam repairs its own
installation again, and nothing of this program's is on its command line. A
patch an earlier version appended is rebuilt to fit at the next apply, or taken
back if it cannot be.
A script somebody puts in front of the client to add a switch of its own is
recognised as a way of starting Steam, rather than as an application to hand
the flag to.
A desktop entry edited in place that the ledger has lost is written again from
the copy kept beside it. Without that, an entry from an older version kept an
older answer for good - a browser patched that way stayed on the flag that
shows the "unsupported command-line flag" bar while every other browser moved
off it in 1.3.0.
A desktop entry that was edited in place is left alone once it carries the
marker, and the only thing that ever writes it again is the undo a change of
flags goes through - which reads the ledger. So an entry the ledger has lost is
one nothing looks at any more: it keeps whatever an older version put on its
command line, and an update that moves browsers to a different flag moves every
browser but that one.
The copy taken before the edit is named after the path, not recorded in the
ledger, and is still there. A marked entry with no ledger line is now put back
from that copy and written again from scratch, which is the same thing the undo
would have done, and it lands in the ledger on the way out.
Only entries edited in place need this. A generated entry is built from the
source entry every time and is right by construction, and a flag file has its
block rewritten whenever the contents differ.
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.
A script somebody puts in front of the client to add a switch of its own is
still a way of starting Steam, but nothing recognised it as one: the check is
by name, and the script is not called steam.
Such a script tends to name the flag it exists to add, and that flag is one of
the markers the hint scan reads as "this is Chromium". The entry was therefore
handled as an application and had the flag appended to every Exec line of it,
where Steam ignores it, instead of being handed to the Steam module - so the
interface it was pointing at never got autoscroll, and the launcher entry never
got Steam's own switch either.
The handover a launcher script makes is now followed one step, and a script
that hands over to Steam counts as Steam. One step is all there is: the
client's own launcher is recognised by name already.
A browser no longer shows the "unsupported command-line flag" bar. It is given
--enable-features=MiddleClickAutoscroll, which asks for the same feature
without being on the list of flags Chromium warns about; everything that embeds
an older Chromium keeps the flag that works there, and shows no bar either way.
Helium gets its own name for the feature alongside it, so autoscroll works
there for the first time.
An installation from 1.2.0 or earlier is taken back and written again on the
next apply.
--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 stops depending on -noverifyfiles: the patch is written at
the size and timestamp Steam recorded, so the client's own file check finds
nothing to repair and the flag survives whichever way Steam was started. An
installation patched by 1.1.0 is redone at the original size on the next apply.
Also picks up the launch paths that were never covered - shortcuts on the
desktop, Steam as a Flatpak, steam-native and steam-jupiter.
Felitendo