My Firefox addons as of Firefox '64' (the current development version)
As I write this, Firefox 62 is the current released version of Firefox and Firefox 63 is the beta version, but my primary Firefox is still a custom hacked version that I build from the development tree, so it most closely corresponds to what will be released as Firefox 64 in a couple of months. At this point I feel that I'm far enough into my Firefox Quantum era that my set of addons has more or less stabilized, especially what I consider my core set, so it's time to write them down (if only for my future reference).
On the whole I've been pleased by how well Firefox Quantum handles addons, and in particular it doesn't seem to have addon memory leaks. As I mentioned in my earlier entry on some addons I was experimenting with, this has made me much more willing to give potentially interesting addons a go. It's also made me much happier with Firefox overall, since I no longer feel like I need to restart it on a regular basis; I'm back to where I can just leave it running and running for as long as my machine is up.
My core addons, things that I consider more or less essential for my experience of Firefox, are:
- Foxy Gestures
(Github) is the
best gestures extension I've found for Quantum. It's better than
the usually recommended Gesturefy for reasons that I covered in
my early entry on Quantum addons. Gestures
have become a pretty crucial part of my Firefox experience and I
really notice the places in Quantum where they don't work, which
is more places than I expected. But that's another entry.
(I use some custom gestures in my Foxy Gestures configuration that go with some custom hacks to my Firefox to add support for things like 'view page in no style' as part of the WebExtensions API.)
- uBlock Origin (Github) is my standard 'block ads
and other bad stuff' extension, and also what I use for selectively
removing annoying elements of pages (like floating headers and
(Github) is my primary tool
cookies as far as I know, and in any case uMatrix gives me finer
- Cookie AutoDelete
deals with the small issue that uMatrix doesn't actually block
cookies, it just doesn't hand them back to websites. This is
probably what you want in uMatrix's model of the world (see my
entry on this for more details), but
I don't want a clutter of cookies lingering around, so I use
Cookie AutoDelete to get rid of them under controlled circumstances.
(However unaesthetic it is, I think that the combination of uMatrix and Cookie AutoDelete is necessary to deal with cookies on the modern web. You need something to patrol around and delete any cookies that people have somehow managed to sneak in.)
- My Google Search URL Fixup for reasons covered in my writeup of creating it.
Additional fairly important addons that would change my experience if they weren't there:
(Github) gives me the ability
to edit textareas in a real editor. I use it all the time when
writing comments here on Wandering Thoughts, but not
as much as I expected on other places, partly because increasingly
people want you to write things with all of the text of a paragraph
run together in one line. Textern only works on Unix (or maybe
just Linux) and setting it up takes a bit of work because of how
it starts an editor (see this entry),
but it works pretty smoothly for me.
(I've changed its key sequence to Ctrl+Alt+E, because the original Ctrl+Shift+E no longer works great on Linux Firefox; see issue #30. Textern itself shifted to Ctrl+Shift+D in recent versions.)
- Open in Browser
(Github) allows me
to (sometimes) override Firefox's decision to save files so that
I see them in the browser instead. I mostly use this for some
PDFs and some text files. Sadly its UI isn't as good and smooth
as it was in pre-Quantum Firefox.
- Cookie Quick Manager (Github) allows me to inspect, manipulate, save, and reload cookies and sets of cookies. This is kind of handy every so often, especially saving and reloading cookies.
The remaining addons I use I consider useful or nice, but not all that important on the large scale of things. I could lose them without entirely noticing the difference in my Firefox:
- Certainly Something
(Github) is my
TLS certificate viewer of choice. I occasionally want to know the
information it shows me, especially for our own sites.
- Make Medium Readable Again
(also, Github) handles a bunch of annoyances for
Medium-hosted stuff. Some of these just automate things that I could
zap by hand with uBlock Origin and some of these only apply when I turn
- Link Cleaner cleans
the utm_ fragments and so on out of URLs when I follow links. It's
okay; I mostly don't notice it and I appreciate the cleaner URLs.
(It also prevents some degree of information leakage to the target website about where I found their link, but I don't really care about that. I'm still sending
Refererheaders, after all.)
- HTTPS Everywhere, basically just because. But in a web world where more and more sites are moving to using things like HSTS, I'm not sure HTTPS Everywhere is all that important any more.
I'm no longer using any sort of addon to stop Youtube and other media from autoplaying. These days, that's mostly covered by Firefox's native media autoplay settings, although I have to add a hack to my personal build so that isolated video documents with no audio don't get to autoplay on their own. I'm happy with this shift for various reasons.
Twelve addons is a significant increase on what I've historically used, but everything seems to go okay so far. At the moment I'm not tempted to add any more additional addons, although some people would throw in major ones like Greasemonkey or Stylus. I've used Stylish in the past, but these days uBlock Origin's element zapping covers basically everything I care about there.
(More commentary on these addons and alternatives is in this early entry on Quantum addons and then this entry on more addons that I was experimenting with. All of those then-experimental addons have been promoted to ones that I'm keeping, especially Certainly Something.)
PS: These days I keep copies of the Github or other repos of all of the important addons that I use for various reasons, including as a guard against what could euphemistically be called 'supply chain attacks' on addons.
Why updating my Fedora kernels is a complicated multi-step affair
Ah, the delicate yak shaving dance of updating my Fedora system's kernel. Life will be easier when WireGuard is in the upstream kernel. (It would be even easier if ZFS in the upstream, but that's sadly probably never going to happen unless Oracle gets very strange.)
You might wonder why updating the kernel is such a complicated thing
for me. Part of the answer is that updating the kernel is, in one
sense, not complicated at all. If all I want to do on my home machine
is update the kernel by itself, all I need to do is run '
"kernel*"' and then wait a while as the RPMs are installed and
rebuilds the kernel modules for WireGuard
and ZFS on Linux for me. In this sense,
having both upstream in the main kernel wouldn't really change
anything (although it would mean no DKMS rebuilds).
But usually this is not all that I want to do, because I'm almost always taking the opportunity of a kernel update to also update WireGuard and ZFS on Linux. I get WireGuard from its Fedora COPR repo, where it updates pretty frequently; there's almost always at least one update by the time there's a new Fedora kernel. ZFS on Linux makes new releases only infrequently, but I don't run release versions; instead I use the latest development versions straight from the ZoL Github repo, where it sees ongoing development.
(It appears that WireGuard currently updates roughly once a week. There have been four updates this September, dated the 4th, the 10th, the 18th, and the 25th.)
Once I'm updating additional DKMS-based packages, DKMS adds its own wrinkle here, because you need to force things to update in the right order. If you install a new kernel in Fedora, part of the kernel updates insure that DKMS will rebuild all current DKMS modules for the new kernel. But if you install or update a DKMS based package, the Fedora setup only has DKMS (re)build kernel modules for the current kernel, not for any kernels that you may have installed and be waiting to reboot. So if you're going to update some DKMS packages and also your kernel, you must update the DKMS packages first and the kernel second.
So my whole update process looks like this:
- Sync up my local ZFS on Linux build repo and build new RPMs.
- Use '
dnf update zfs/*.rpm' to install the new version, which (slowly) builds the new DKMS kernel modules for my current kernel.
- Do '
dnf update "wireguard*"' to update the WireGuard packages, which will build its new kernel module for my current kernel.
- Finally do '
dnf update "kernel*"', which installs the new kernel and has DKMS rebuild the just-installed new ZFS and WireGuard kernel modules for the new kernel.
When WireGuard goes into the kernel, what will be different is that it will stop changing so much, or at least the version I use would stop changing so much because it would be whatever version was in the Fedora kernel. The same would be true if ZFS was somehow put into the Linux kernel; I would stop running the latest development version and just stick with whatever the Fedora kernel had.
So, really, I've done this to myself. I could run a released version of ZFS on Linux, which would basically stop that from updating all the time, and I could probably just freeze my WireGuard version for a month or two if I wanted to.
(Updating the kernel on my work machine takes an extra step because I have not yet put in the effort to DKMS-ize the special kernel modules for VMWare Workstation, so I have to run a couple more commands to rebuild them every time. These days I can at least do this before I reboot into the new kernel; I used to have to reboot into the new kernel, rebuild the modules, and then reboot again to get everything fully activated with the right magic.)