Why I still have a custom-compiled Firefox (early 2019 edition)

January 10, 2019

For years, I've had a custom-compiled version of Firefox with various personal modifications, generally built from the current development tree. The number of modifications has fluctuated significantly over time; when I first wrote about my history of custom-compiling Firefox in this 2012 entry, it was probably my minimal point for modifications. These days my version has added significantly more changes from the stock version, in larger part due to Firefox's switch to WebExtensions. The somewhat unfortunate thing about this increase in changes is that having this custom Firefox is now more than a little bit important to get the Firefox user interface I really want. Abandoning my custom-compiled Firefox would be something that I'd definitely notice.

The largest set of changes are to deal with Firefox irritations and limitations. In the irritations department, I modify Firefox's current media autoplay code to turn off autoplay for a couple of things that Firefox doesn't otherwise allow you to stop (bare videos and videos with no audio track). In the limitations department, I add a couple of new WebExtensions APIs, which turns out to be surprisingly easy; one API provides 'view page in no style', and the other provides an API to open your genuine home page (as if you did Control-N), which is not otherwise possible in standard Firefox.

(A WebExt can open about:home, but that is actually about:newtab, not your genuine home page. My actual home page is a file: URL, which can't be opened by WebExt addons.)

My longest standing change is customizing how Firefox's remote access works, which these days also has me customizing the DBus remote control. The current development tree for Firefox seems to go back and forth about whether DBus should be used under X, but I cover my bases to be sure.

For extremely historical reasons I change the Delete key to act like the Backspace key in HTML context. This is probably surplus now, because several years ago I stopped swapping Backspace and Delete so now the key I reflexively hit to scroll the page up generates a Backspace, not Delete. Anyway, these days I often use Control-Space instead, because that works even in stock Firefox setups.

(This is about:config's browser.backspace_action setting, and I don't think it's exposed in the Preferences UI any more. I don't think I'm quite up to abandoning Backspace entirely just yet, though.)

I modify Firefox's standard branding because on the one hand, I don't want my builds to be called 'Nightly' in window titles and so on, and on the other hand I don't want them to use the official icons or otherwise actually be official builds. I also turn out to have some small changes to the default preferences, in the all.js file. I could probably do most or all of these in my own prefs.js; they linger in all.js due to historical inertia. Finally, a few years ago I did a little about the mess that is Firefox's certificate manager UI by changing Firefox's name for 'private tokens' from 'Software Security Device' to the generally more accurate 'Locally Stored Token'. I'm not sure this genuinely improves things and perhaps I should drop this change just to be more standard.

(I used to manually modify my certdata.txt to remove various CAs that I didn't like, but these days I've concluded it's too much work and I use the stock one.)

Building Firefox from source, even from the development tree, does have some potentially useful side effects. For a start, custom built versions appear not to report telemetry to Mozilla, which I consider useful given Mozilla's ongoing issues. However it can also have some drawbacks (apart from those inherent in using the latest development tree), which is a matter for another entry.

As a side note, it's interesting to see that back in my 2012 entry, I'd switched from building from the development tree to building from the released source tree. I changed back to building from the development tree at some point, but I'm not sure exactly when I did that or why. Here in the Firefox Quantum era, my feeling is that using the development tree will be useful for a few years to come until the WebExts APIs get fully developed and stabilized (maybe we'll even get improvements to some irritating limitations).

(It's possible that I shifted to modifying and regularly updating the development tree because it made it easier to maintain my local changes. The drawback of modifying a release tree is that it only updates occasionally and the updates are large.)

Comments on this page:

By Jukka at 2019-01-10 08:17:09:

Kudos for even putting effort to maintain local changes for Firefox. I stopped already a long ago (could it be a decade?) my attempts to deal with or generally understand this particular project and its source code base.

The technical irritations are one thing. Another -- and perhaps more important -- thing is that Firefox/Mozilla is an "unhealthy" open source community. Good luck with discussing issues with them, proposing patches to them, issuing bug reports to their trackers, or doing practically anything that makes open source tick community-wise. I'd take LKML or even @misc any day compared to this community.

As someone was kind of hinting in a related entry, there is also a societal viewpoint in addition to the technical and open source viewpoints. I fear that Firefox is a lost cause. A good question for the historians of technology; was it when Google adopted Firefox as its lapdog when Mozilla lost its way?

By Jukka at 2019-01-10 08:36:00:

A small remark to the above comment: I did look at the source when they decided to stop providing audio for anything else than the certain other open source trainwreck. But, well, I quickly realized that it is probably for the better. After all, when it comes to browsers, the lesser the functionality, the better the overall result for users (cf. security, privacy, and all that).

I add a couple of new WebExtensions APIs [...] one API provides 'view page in no style'

NB there is a way to do this using only existing Firefox WebExt APIs. You can iterate through the stylesheets and disable them.

I used this for the "disable all styles" key shortcut in my addon: https://addons.mozilla.org/en-US/firefox/addon/margin_annihilator/

I stole this method from Chris Pedrick's Web Developer Toolbar extension. Credit goes to him for working it out.

Unstyled page display cannot be emulated by disabling stylesheets alone, because that also prevents style attributes from taking effect. And if you want to be thorough, you can’t emulate that just by walking the DOM once, either, because it happens even for DOM nodes created later by Javascript – you need a mutation observer for that. Overall, I don’t know if a truly comprehensive emulation of the “View Page → No Style” toggle can even be done, and I’m certainly not confident that it can be relied on to stay comprehensive as the web evolves. But even a minimal partial solution is plenty complicated.

(And it also gets more complicated along another axis if it’s supposed to be reversible without a page reload, like the toggle.)

Sidenote: I'm probably taking a more consequential view of disabling stylesheets ('whatever works'). My addon is not perfect, from an intentionalist viewpoint I don't think there is a perfect solution that balances "simple" and "feature complete". Other than getting Mozilla to change that is, but that's another topic :P

Unstyled page display cannot be emulated by disabling stylesheets alone, because that also prevents style attributes from taking effect.

[can't prevent]?

Yes, it does not affect inline style attributes, eg <div style='color: red;'></div>. I was worried about this too, but I've generally not found it to be an issue.

DOM nodes created later by Javascript

Yes, this method won't keep track of any new DOM/styles/etc added by javascript (technically there may be some corner cases with JS modifying existing stylesheets, but I have not tested).

From a developer's perspective: this is an imperfect solution.

From a user's perspective: I think I've only encountered one site where this was ever a problem. There are probably more, but it's mostly fine.

But even a minimal partial solution is plenty complicated.

I'd be cautious calling an attempt to tackle the javascript problem 'minimal'. That would indeed be hairy.

Simpler solutions are often good enough. I didn't want to follow the footsteps of reader mode and make something that stumbles over itself.

supposed to be reversible without a page reload, like the toggle.

N.B. Pedrick's extension already implements this. I am too lazy, plus my addon technically adds a bit off CSS back in (notably img{max-width:100%;}) that would also need tracking. /Most/ of the time refreshing the page is an OK workaround.

It certainly doesn’t have to be perfect to be useful. But I found that the emulation is imperfect enough to regularly draw attention to that fact in small ways, reminding me that I lost something. It’s not a big loss functionally… but a meaningful one in terms of the seamlessness and reliability that makes a feature invisible and a no-brainer to use.

From an intentionalist viewpoint I don’t think there is a perfect solution that balances “simple” and “feature complete”.

Yeah. Unless you are in Chris’ position, of already maintaining a personal custom build of Firefox, and already having figured out how to patch in custom WebExtension APIs… whence the cost of the perfect solution is marginal.

Written on 10 January 2019.
« On right and wrong ways to harvest system-level performance stats
A new drawback of using my custom-compiled Firefox »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Jan 10 01:16:56 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.