Wandering Thoughts

2018-02-12

Writing my first addon for Firefox wasn't too hard or annoying

I prefer the non-JavaScript version of Google search results, but they have an annoyance, which is that Google rewrites all the URLs to indirect through themselves (with tracking numbers, but that's a lesser annoyance for me than the loss of knowing what I've already read). The Firefox 56 version of NoScript magically fixed this up, but I've now switched to uMatrix.

(The pre-WebExtensions NoScript does a lot of magic, which has good and bad aspects. uMatrix is a lot more focused and regular.)

To cut a long story short, today I wrote a Firefox WebExtensions-based addon to fix this, which I have imaginatively called gsearch-urlfix. It's a pretty straightforward fix because Google embeds the original URL in their transformed URL as a query parameter, so you just pull it out and rewrite the link to it. Sane people would probably do this as a GreaseMonkey user script, but for various reasons I decided it was simpler and more interesting to write an addon.

The whole process was reasonably easy. Mozilla has very good documentation that will walk you through most of the mechanics of an addon, and it's easy enough to test-load your addon into a suitable Firefox version to work on it. The actual JavaScript to rewrite hrefs was up to me, which made me a bit worried about needing to play around with regular expressions and string manipulation and parsing URLs, but it turns out that modern Firefox-based JavaScript has functions and objects that do all of the hard work; all I had to do was glue them together correctly. I had to do a little bit of debugging because of things that I got wrong, but console.log() worked fine to give me my old standby of print based debugging.

(Credit also goes to various sources of online information, which pointed me to important portions of the MDN JavaScript and DOM documentation, eg 1, 2, 3, and 4. Now you can see why I say that I just had to connect things. Mozilla also provides a number of sample extensions, so I looked at their emoji substitution example to see what I needed to do to transform the web page when it had loaded, which turned out to be a pleasantly simple process.)

There are a couple of things about your addon manifest.json that the MDN site won't tell you directly. The first is that if you want to make your addon into an unsigned XPI and load it permanently into your developer or nightly Firefox, it must have an id attribute (see the example here and the discussion here). The second is that the matches globs for what websites your content scripts are loaded into cannot be used to match something like 'any website with .google. in it'; they're very limited. I assume that this restriction is there because matches feeds into the permissions dialog for your addon.

(It's possible to have Firefox further filter what sites your content scripts will load into, see here, but the design of the whole system insures that your content scripts can only be loaded into fewer websites than the user approved permissions for, not more. If you need to do fancy matching, or even just *.google.*, you'll probably have to ask for permission for all websites.)

This limitation is part of the reason why gsearch-urlfix currently only acts on www.google.com and www.google.ca; those are the two that I need and going further is just annoying enough that I haven't bothered (partly because I want to actually limit it to Google's sites, not have it trigger on anyone who happens to have 'google' as part of their website name). Pull requests are welcome to improve this.

I initially wasn't planning to submitting this to AMO to be officially signed so it can be installed in normal Firefox versions; among other things, doing so feels scary and probably calls for a bunch of cleanup work and polish. I may change my mind about that, if only so I can load it into standard OS-supplied versions of Firefox that I wind up using. Also, I confess that it would be nice to not have my own Firefox nag at me about the addon being unsigned, and the documentation makes the process sound not too annoying.

(This is not an addon that I imagine there's much of an audience for, but perhaps I'm wrong.)

FirefoxMyFirstAddon written at 23:59:21; Add Comment

2018-02-04

More notes on using uMatrix in Firefox 56 (in place of NoScript)

I wrote my first set of notes very early on in my usage of uMatrix, before things had really settled down and I mostly knew what I was doing it. Since then I've been refining my configuration and learning more about what works and how, and I've accumulated more stuff I want to record.

The first thing, the big thing, is that changing from NoScript to uMatrix definitely seems to have mostly solved my Firefox memory issues. My Firefox still slowly grows its memory usage over time, even with a stable set of windows, but it's doing so far less than it used to and as a result it's now basically what I consider stable. I certainly no longer have to restart it once every day or two. By itself this is a huge practical win and I'm far less low-key irritated with my Firefox setup.

(I'm not going to say that this memory growth was NoScript's fault, because it may well have been caused by some interaction between NS and my other extensions. It's also possible that my cookie blocker had something to do with it, since uMatrix also replaced it.)

It turns out that one hazard of using a browser for a long time is that you can actually forget how you have it configured. I had initial problems getting my uMatrix setup to accept cookies from some new sites I wanted to do this for (such as bugzilla.kernel.org). It turned out that I used to have Firefox's privacy settings set to refuse all cookies except ones from sites I'd specifically allowed. Naturally uMatrix itself letting cookies through wasn't doing anything when I'd told Firefox to refuse them in the first place. In the uMatrix world, I want to accept cookies in general and then let it manage them.

Well, more or less. uMatrix's approach is to accept all cookies but only let them be sent when you allow it. I decided I didn't entirely like having cookies hang around, so I've also added Self-Destructing Cookies to clean those cookies up later. SDC will also remove LocalStorage data, which I consider a positive since I definitely don't want random websites storing random amounts of things there.

(I initially felt grumpy about uMatrix's approach but have since come around to feeling that it's probably right for uMatrix, partly because of site-scoped rules. You may well have a situation where the same cookies are 'accepted' and sent out on some sites but blocked on others. uMatrix's approach isn't perfect here but it more or less allows this to happen.)

Another obvious in retrospect thing was YouTube videos embedded in other sites. Although you wouldn't know it without digging under the surface, these are in embedded iframes, so it's not enough to just allow YT's JavaScript on a site where you want them; you also need to give YT 'frame' permissions. I've chosen not to do this globally, because I kind of like just opening YT videos in another window using the link that uMatrix gives me.

I have had one annoying glitch in my home Firefox with uMatrix, but once I dug deep enough it appears that there's something unusual going on in my home Firefox 56. At first I thought it was weird network issues with Google (which I've seen before in this situation), but now I'm not sure; in any case I get a consistent NS_ERROR_FAILURE JavaScript failure deep in Google Groups' 'loaded on the fly' JS code. This is un-debuggable and un-fixable by me, but at least I have my usual option to fall back on.

('Things break mysteriously if you have an unusual configuration and even sometimes if you don't' is basically the modern web experience anyway.)

PS: A subtle benefit of using uMatrix is that it also exists for Chrome, so I can have the same interface and even use almost the same ruleset in my regular mode Chrome.

PPS: I'll have to replace Self-Destructing Cookies with something else when I someday move to Firefox Quantum, but as covered, I already have a candidate.

FirefoxUMatrixNotesII written at 01:59:09; Add Comment

2018-01-31

Mozilla's Looking Glass 'retrospective' is unfortunately inadequate

You may remember Mozilla's betrayal of Firefox users and its nominal principles when it force-pushed a misleading named and described promotional addon through its SHIELD studies system. Mozilla ate a certain amount of crow at the time and promised a postmortem about the whole thing. They have finally delivered with Retrospective: Looking Glass (via). Unfortunately there are problems (still).

Things go bad right at the start of the retrospective:

In December, we launched a tv show tie-in with Mr. Robot, Looking Glass, that alarmed some people because we didn’t think hard enough about the implications of shipping an add on that had the potential to be both confusing and upsetting. [...]

Either Mozilla did not take their root analysis far enough to understand the core problem or they're still not willing to admit it: when Mozilla force-pushed Looking Glass, they betrayed the trust of Firefox users. The problem is not the addon that they shipped, the problem is that they shipped the addon.

Mozilla's retrospective does admit that they misused the SHIELD system and they have announced new principles to stop them from doing this in the future. But as long as their root problem is not addressed, this is simply blocking one particular mechanism (out of many possible ones) instead of putting an end to the philosophy. I find it not particularly surprising but still depressing that this retrospective does not come very close to addressing the questions I would like Mozilla to be asked, starting with 'do you think you have to right to do this sort of thing without informed consent from users'.

(Perhaps Mozilla thinks the answer to that is obvious and is 'of course we don't'. Well, given Looking Glass, that answer is no longer obvious to people outside Mozilla (at least), so Mozilla should be reaffirming it in public and re-committing themselves to it. As it stands, their silence here on this leaves at least doubts.)

Since Mozilla apparently doesn't understand that people gave them trust and they betrayed that trust, I don't think they can necessarily be trusted in the future. Whether you re-enable SHIELD studies in light of Mozilla's new principles for their use is up to you, but if you do you should do it because you explicitly want to do Mozilla a favour and you're willing to take the risk that Mozilla will 'abuse' the mechanism in the future.

(I put 'abuse' in quotes because Mozilla probably will claim and perhaps honestly think that whatever they do isn't an abuse of their stated principles. That's kind of the problem with Looking Glass; Mozilla demonstrated that they were blind to what they were doing (wilfully or otherwise).)

As far as future questionable Mozilla decisions go, well, I'm not planning on giving Mozilla the benefit of the doubt any more. If they put forward a potentially dubious feature and ask me to trust them that it's a good thing and won't be abused, my new answer is 'no'. As a result, I will be turning off this Pocket stuff and other future things as forcefully as I can manage.

MozillaStillTrustProblems written at 23:05:29; Add Comment

2018-01-30

Reverse engineering some settings for Google Search

As part of switching to uMatrix, I wound up destabilizing my Google cookies and thus more or less destroyed my old Google search settings (as I mentioned in passing in the original entry). This isn't the first time something like this has happened, but this time around I've managed to work out roughly what all of the magic processes are to manipulate them back to the way they used to be.

Google Search has at least three separate settings:

  • The straightforward search preferences for things like how many results are displayed on a single page. Google directly supports changing these through their search settings.

    (There are two versions of this settings page; see the end.)

  • Whether or not visiting google.com redirects you to your country Google domain (I believe the term for this is a 'country redirect'). You can turn off country redirects by visiting the magic URL www.google.com/ncr, which sets some opaque magic cookie value. I don't know how you turn country redirects back on, or if there's any way short of deleting your Google cookies.

    (As you can tell, I always turn country redirects off and leave them off. When I go to google.com, that's where I want to be; if I wanted google.ca, I would go there explicitly. I believe that Google still gives me somewhat location-based results, but at least I usually get to see the Google doodles.)

  • Whether you get what I'll call the non-JavaScript results page [JPG] or the JS results page [JPG]. One difference between these two pages that isn't obvious in my screenshots is how the URLs are handled. In the non-JS version, Google rewrites all of the actual links to be redirected through themselves for click-tracking. In the JS version, the links are intact and this tracking is done through an onmousedown attribute.

    (The JS version will do various things not pictured here, such as put in images and other content. The non-JS version sticks to plain, straightforward search results.)

    To complicate the picture, some Firefox addons (at least NoScript) will apparently fix Google's link mangling in the non-JS version, although this fixing isn't necessarily instant or complete.

How the two versions of the results page switch back and forth is complicated. As far as I can tell, it goes like this:

  • If you have JavaScript turned off and interpret <noscript> tags, you get the non-JS version, with all of the URL links rewritten to go through Google with tracking information. Google also sets a magic cookie so that this state is persistent as long as you have JS off (even if you later stop interpreting <noscript> tags).

    (If you have the magic cookie, your search result is immediately the non-JS page. If you don't, you first wind up on the JS page but a <noscript> tag redirects you to the non-JS version.)

  • If you have JavaScript turned on for Google, you get the JS version (and Google tracks your clicks on the URLs through JS). Doing a search with JS on clears the magic cookie from above.

  • If you have JS off, don't interpret <noscript> tags, and don't have the magic cookie, you get the JS version (with a <noscript> tag that would redirect you to the non-JS version if you were to interpret it). Since it's the JS version, it has the URLs not mangled (and your history works so you know if you've already read a search result), but since you're not interpreting JS, Google doesn't get to track your clicks.

I don't allow Google to run JavaScript (for all sorts of reasons). My NoScript setup interpreted <noscript> tags and also de-mangled the Google-mangled URLs in the non-JS version, which is the ideal outcome. My uMatrix setup doesn't interpret <noscript> tags and doesn't de-mangle the Google-mangled URLs if I get the non-JS page. The non-JS page fits within my normal browser window width; the JS page does not (even with JS off). However the JS page does give me real URLs that I can see if I've visited before, and if I scroll the window sideways all of the search content fits.

Until I did the experimentation for this entry, I didn't know how to switch my current uMatrix setup over to the non-JS version. Now that I do, I'm still going to stay with the JS version for the better URLs for now, although I may get irritated with its various annoyances and change my mind.

(There's probably a GreaseMonkey user script to fix the URLs, but I've had memory leak problems with GreaseMonkey in the past so I'm not entirely enthused about the idea of re-enabling it. In theory I could probably also write a Firefox WebExtension addon to do this, since it's just modifying the href attribute of <a> elements that match a specific pattern.)

As a side note, the search settings page actually comes in two versions, a 'JavaScript' version and a non-JS one (by analogy to the search results pages). You get the non-JS version if and only if you have the magic cookie that forces you to the non-JS search page right away; having JS turned off is not enough by itself to get the non-JS settings page. This can be confusing and annoying, especially since the JS settings page doesn't work if you have JavaScript turned off.

GoogleSearchSettings written at 00:03:50; Add Comment

2018-01-28

The limitations of Firefox's Reader mode

Firefox has had a special Reader mode for a long time now. Since I find that many web pages are badly styled in ways that make them hard to read, or at least annoying, I resort to it periodically. However it has a number of limitations that are fundamental to what it does. Put simply, Reader mode hunts through the page to find the important content and present it to you with minimal styling.

This opens up a number of limitations:

  • Reader mode may not be able to analyze the page, even though you can see the content with your eyes. For example, in an amusing irony it currently doesn't seem to be able to generate a Reader view of its own Mozilla support page.

  • Reader's idea of where the page's content ends (or starts) may not match reality, so that it truncates the text before the actual end or skips some of the start, or both.

  • Reader can omit portions of the content that it thinks are unimportant (or not actually content, as opposed to ads or whatever shoved into the middle). Depending on what you're reading, the omissions may or may not be obvious.

  • Reader doesn't necessarily render content correctly, depending on how that content is formed into the article. One may reasonably criticize sites like Medium for making it necessary to enable JavaScript and iframes to see things like this article with all its (necessary) content, but they are what they are, and Reader isn't doing you a service by not showing much of that (for whatever reason).

  • Reader's content flattening can give you terrible results for certain sorts of content, such as code and output in <pre> blocks. In the case of the Medium article, the code blocks are forced to line-wrap and Reader just won't show them in a single line no matter how wide I make the browser window.

    (In general Reader seems to not like going very wide, which is another limitation; you're at the mercy of its view of what a 'plain' style means.)

An issue that is not a limitation as such is that Reader's styling doesn't necessarily work for all content. Some content simply has been structured in part based on how it looks (and this is not wrong); when Reader comes along and changes that look, the writing may not work as well. In somewhat stronger cases, the original visual appearance is important for understanding the content or having it flow right and of course Reader's rendition will be completely different.

(This is where people chime in about sticking to semantic markup. I used to be a fan of the idea, but I've come around to feeling otherwise for various reasons well beyond the scope of this entry (I'm surprised that I haven't already written an entry here on that, but apparently not).)

All of these limitations of Reader mode are why I often resort to what I call 'view page in no style' (View → Page Style → No Style). Turning off all CSS is a blunt hammer and doesn't always work all that well, but it definitely doesn't exclude any content (if anything, it includes too much) and it doesn't mangle <pre> blocks of code. In fact I do this so often that I added a FireGestures user script to toggle it and bound the script to a simple gesture (I use Right-Left, which is trivial to do rapidly).

PS: If you want the JavaScript for said user script, it is:

getMarkupDocumentViewer().authorStyleDisabled = !getMarkupDocumentViewer().authorStyleDisabled;

This only works in Firefox 56 and before, obviously, since FireGestures itself is not a WebExtensions addon and so doesn't work in Firefox Quantum (57+). Sadly, according to the author of Foxy Gestures, 'view page in no style' (as a toggle or otherwise) can't be done in Firefox 57+ because WebExtensions have no API for it (see my feature request for this). Perhaps Firefox will add a new WebExt API eventually, but I'm not holding my breath.

PPS: Toggling Reader mode is available as a WebExtensions API (here), so you can at least add a gesture for that to Foxy Gestures if you want. I suspect that the presence of this API means that Mozilla would reject requests for 'view page in no style' on the grounds that the 'right' solution is improving Reader mode.

FirefoxReaderModeLimitations written at 02:41:09; Add Comment

2018-01-24

Some early notes on using uMatrix to replace NoScript in Firefox 56

Although people have been suggesting uMatrix (Github) to me for a while, it took Aristotle Pagaltzis' plug for it as his preferred JavaScript blocker in comments on yesterday's entry to push me into giving it a serious look. First, I took it for a spin in the Firefox on my laptop and then, somewhat impulsively, I decided to try switching from NoScript (and my cookie blocking extension) to it on my home machine. Having spent a couple of hours with it, I'm sold so far and will be switching my office Firefox over to it tomorrow.

I have three main reasons for this rapid enthusiasm. First, uMatrix gives me more fine-grained control over where and when JavaScript is enabled, because I can say 'JavaScript for X is only enabled when I'm on site Y'. Second, uMatrix's cookie blocking and cookie handling works, which means that I finally have a reliably working cookie-handling addon; my old one has been unsupported and only partially functional for years. However, the single largest reason I'm so enthused is that my Firefox appears to use significantly less memory with uMatrix. Firefox is definitely using significantly less memory on startup (once it loads all of my current set of windows) and I think it hasn't been leaking memory as fast.

(Some of this may be because of configuration differences in what JavaScript I'm allowing to run, but if so that's because uMatrix lets me do fine-grained things like only run YouTube's JS on YT itself, not on random sites that want to embed YT videos.)

Since I'm using uMatrix to replace NoScript and a cookie blocking extension, I have it set to default-deny JavaScript and cookies, with permanent exemptions for only a few specific sites. Figuring out how to set this up and to configure exemptions took a bit of reading of help material and experimentation, but once I got in tune with how uMatrix's UI works, working with it is relatively problem free. Setting up permissions on the BBC website was a bit tricky because I got myself into a redirect loop with an incomplete set of JavaScript allowances, but I was able to get things set in the end. A useful trick to learn was that I could make changes persistent in the uMatrix preferences dialog (in 'My rules', you can pick 'commit'); this is handy when enabling a rule immediately redirects you off a site.

(Since I'm also using uBlock Origin, I turned off all of uMatrix's site blocklists as just being duplication.)

uMatrix's Javascript blocking is more powerful than NoScript's because in uMatrix you normally scope permissions by the site you're visiting whereas NoScript only gives you global ones. In NoScript, if you enable JavaScript for Youtube, it's enabled on every site; in uMatrix I can say 'enable Youtube's JavaScript only when I'm visiting YouTube' (and this is the default way you'll set it up). This has made me much more willing to permanently enable various bits of third party JS on specific websites.

(This wide use of scoped permissions does make it harder to get a relatively global overview of what your permissions are. Of course part of this is that you're probably going to have more rules than you would have had in NoScript; I know that I do.)

When I switched over to uMatrix, I ran into my old Twitter no-JS endless redirect problem. In NoScript, this was fixed by a magic option to ignore META redirections in <noscript> elements. uMatrix does not have such a magic option, so I wound up turning off its 'spoof <noscript> tags' setting. This turns out to have useful side effects (for example, it turns out that Stack Overflow's obnoxious red 'we're better with JS' banner is in a <noscript> element). However, some things don't work with this off, such as external links on Tumblr sites. Fortunately uMatrix lets you enable this on a per-site basis.

(I believe that uMatrix also lets you disable <noscript> spoofing on a per-site basis, so in theory I could leave it enabled everywhere and just disable it on Twitter. But since the side effects of disabling it globally seem to be mostly positive, I'm sticking with my default-off for now.)

So far using uMatrix's UI has been reasonably non-annoying. There are some fiddly bits and I'm probably not using it in the best way possible, but I can get things done and it's not too painful. I don't expect to need to use it very often, especially once I've gotten things all tuned up; if a site wants JavaScript, mostly I feed it to another browser.

(So far the most annoying bit of the transition is that my Google search settings got damaged, again. If you do things just right, Google will give you cookies so that you get a nice, functional search experience even without JS and will stick to google.com; however, the settings are quite fragile, fall off easily, and there's no obvious way to fully set yourself back to them.)

FirefoxUMatrixNotes written at 02:24:17; Add Comment

2018-01-22

The addons that I would likely use with Firefox Quantum (57+)

A significant number of my current Firefox addons are not WebExtesions based addons and so don't work in Firefox 57 and later. Since I'm going to have to move on from Firefox 56 at some point (although probably not soon, temptation notwithstanding), I've been checking in on the state of WebExtensions addons and putting together a snapshot of the addons that I would likely end up using if and when I move over.

(Since Firefox WebExtensions addons are very new at this point and some addon maintainers are undoubtedly getting to experience the charms of unexpected and not entirely welcome popularity, I would be surprised if this list did not change over the next six months or so.)

The simple case is current addons that already have Quantum-okay versions. In this category are NoScript, uBlock Origin, Open in Browser, and HTTPS Everywhere. I'm not exactly fond of the new NoScript interface (I find it much more confusing than the old Firefox 56 NoScript UI), but I'm sure I could get used to it.

As far as everything else goes:

  • Foxy Gestures appears to be the leading replacement for FireGestures. The FG Github site has a bunch of useful information, including about current inherent limitations in WebExtensions that affect Foxy Gestures. The leading other option is probably Gesturefy, which I haven't experimented with (and it seems less actively developed, which matters when the Firefox WebExtensions API is actively changing as people tell Mozilla what they left out).

  • My preferred way to deal with cookies is the 'don't allow cookies at all' approach. Unfortunately, it seems that everyone has moved over to the 'accept cookies then delete them later' model (as far as I can see from picking through addons.mozilla.org). The modern addon for this that I'm trying out is Cookie AutoDelete, partly because it's developed in the open on Github.

    (For all that I grumble about this, accepting cookies and then throwing them away may make various websites somewhat more usable. On the other hand, I already read enough random things on the Internet as it is.)

  • The replacement for It's All Text that I've experimented with so far is Textern; it has a somewhat convoluted install process but once installed it appears to be close to the It's All Text experience. Textern uses Native Messaging (also, and), which is pleasantly straightforward compared to some of the alternate approaches taken by other addons. The one thing I've had to remember is that its magic file needs to be installed into every strongly isolated Firefox instance.

    (The It's All Text Github repo mentions some other alternatives. Everything I've looked at so far appears to have a pretty heavyweight process for going from adding the extension to 'edit textarea in vim in an xterm', although they're probably better if you want deep integration into a highly advanced editor.)

  • The alternatives to FlashStopper that I've been looking at are Disable Autoplay for YouTube and Disable HTML5 Autoplay but neither of them get stellar reviews; there's also this. Some flaws may be inevitable in the brave new world of WebExtensions, where apparently at least some addon operations have to wait for the page's DOM to be fully realized, whereas YouTube's player can start up before then. Or maybe there aren't any really good Firefox extensions here yet.

    Apparently setting the media.autoplay.enabled preference to false may also do this, but there are reports of side effects (and when I look at the Firefox source code, I can't convince myself that this disables all video autoplay in all situations). Or I could see if the WebExtension version of NoScript can handle this on its own now.

(In looking at things to make Youtube less annoying, I just stumbled over YouTube Stop AutoPlay Next. I hate that particular YouTube behavior so I may experiment with this at some point.)

It's quite possible that I've missed some good options for replacement addons here. In fact, given that some areas are a bit disappointing, I actively hope that I have (and that I can find the better choices someday). And of course I have no idea whether these new addons (or in some cases new WebExtensions versions) will handle memory any better than my current set of addons do. Since I have had terrible luck with changing addons in the past, I live in moderate fear that they'll be worse, which is one reason I am so unenthused about changing anything about my relatively precarious addon environment. It may leak a bit now, but it could be much worse (and has been in the past).

FirefoxQuantumLikelyAddons written at 22:41:23; Add Comment

2018-01-21

The temptation of Firefox Quantum for me

I'm very down on Firefox 57 and later because of how it breaks almost all of my existing addons with at best inferior replacements, and my expressed plan is to stick to Firefox 56 for as long as possible. But at the same time Firefox Quantum and the addons reset it means is kind of a temptation for me.

One of the consequences of my trick for rapidly starting new Firefox windows combined with how I stay logged on to my desktop all the time is that I naturally keep a single Firefox process running for a long time (I've mentioned this before). In theory I start Firefox when I boot my machine up and log in, then leave it running for days or even weeks until I reboot my machine for some reason. A long time ago, I could actually use Firefox like that; my Firefox process would run stably for weeks or even sometimes months. I can't do that these days, because my Firefox setup semi-slowly leaks memory and over the course of no more than a few days becomes too slow to be pleasant. I've said before that I've become resigned to this, but that's not really true. For all that I've crafted ways to make quitting and restarting Firefox not too painful, it's still somewhat painful to do so and it's simply irritating.

(How fast my Firefox leaks memory seems to depend on what I do with it and how actively I use it. Informally, Youtube videos seem especially bad, and with my active use at home I can run a Firefox session into 'too much memory usage' in less than a day.)

This is where the temptation of Firefox Quantum comes in, because it's possible that it fixes my memory leak issues (or at least significantly improves them). Quantum certainly has a completely different model of addon handling, which matters since addons seem to be the source of most of my memory leaks, and I believe that Quantum is supposed to be better about memory in general. I have a history of abruptly making radical changes when I'm dissatisfied with the status quo, which I am with Firefox, and there is this voice whispering to me that I'm going to have to upend all of my addons sooner or later so I might as well get it over with now.

(The counter-argument to that voice is that the WebExtensions API is clearly a work in progress and probably will be improving for months, so addons now are likely clearly worse than they will be in the future.)

Trying out Firefox Quantum would be somewhat more tempting if it was clearly a reversible thing, where I could cleanly go back to Firefox 56 if it didn't improve things. However I'm pretty sure that it's not, at least not in practice, if only because the moment I update I believe that at least two of my current addons may irreversibly migrate to their WebExtensions form. Of course I could always save my entire Firefox profile directory and then just restore it all afterward, but that probably involves losing recent browser history (which I care about).

(I have been forced to use Firefox 57 on some other machines and I have a test build of the latest Mozilla development Firefox, so I've done some experimenting with the WebExtensions addons I'd need. As far as I know there's still no great replacement for It's All Text, though; the closest is things like GhostText, Textern, and withExEditor, but they work in a somewhat different and more awkward way. Maybe Textern would be good enough.)

FirefoxQuantumTemptation written at 02:33:20; Add Comment

2017-12-20

I feel that Firefox forks that would be useful to me are doomed

One of people's reactions to the Firefox 57 (Quantum) change in addon support, as well as recent events, is to switch to Firefox-based browsers such as Waterfox. I looked briefly at Waterfox at one point but my gut wasn't happy, so I've sat on it ever since. After the most recent events made me think about it again, I've figured out what I feel about it. The summary is that unfortunately, I think that the useful (to me) version of Waterfox is basically doomed, as is any similar Firefox fork or derivative.

First, let's distinguish between a Firefox fork and a Firefox derivative. Both start with the upstream Firefox and then take things out (such as Pocket) or make other changes, but a derivative intends to keep up to date with changes in the upstream version while a fork splits away and doesn't intend to track the main Firefox codebase (it may selectively import changes). Maintaining and developing a fork is far more work than maintaining a derivative because importing upstream changes is far harder.

As I discovered, it's not possible to be a straightforward Firefox derivative that supports old addons, as Mozilla broke or removed that code in the Firefox codebase after Firefox 56. If you want to support old addons you pretty much need to be a Firefox fork now, breaking from Mozilla's Firefox development at the tail end of Firefox 56. If you stay a derivative, you have to abandon support for old addons as you move into being derived from the Firefox 57 and later codebase.

However, if you become a fork of Firefox you stop getting easy performance improvements, feature additions, bug fixes, and most importantly security updates. At the best, you will have to do increasingly more work to selectively extract various changes from the upstream Firefox code; at the worst, the changes you want will have to be reimplemented more or less from scratch because the upstream changes are too entangled in new Firefox 57+ only code that you can't take. Even basing a Firefox derivative on the current Firefox ESR only buys you a few more months before you'll be on your own, when Mozilla releases the next Firefox ESR and stops doing updates to the current ESR code base.

Given all of this, I believe the practical choices facing current Firefox derivatives are either the doom of stagnation (and security exposures) because they don't have the development resources required to go at it alone, or abandoning compatibility with old addons in order to keep tracking the upstream Firefox. We aren't so lucky as to be able to simultaneously get a major difference from upstream (supporting old addons) and easy tracking of upstream.

PS: The obvious concern is security issues more than performance, bugs, or new features. Firefox has security issues from time to time, even on Linux, and people may target them, and anything based on Firefox 56 is now entirely on its own for security fixes. Today's Firefox ESR is a better code base for that since Mozilla is still fixing security issues in it, but current profiles are incompatible with ESR and, as mentioned, switching to ESR as a base only gets you a few more months anyway.

Firefox56ForksViews written at 00:40:13; Add Comment

2017-12-17

Some questions someone should ask Mozilla

I'm still quietly angry about Mozilla's betrayal, even though perhaps I shouldn't be because, as Drew DeVault wrote, Mozilla has been on a slippery slope for a while. Since I can't let this go yet, here are some questions I would like Mozilla to answer because I think they cut to the heart of the larger scale issues here.

  1. Does Mozilla believe it has the right to modify people's Firefox installs without their meaningful informed consent?

    (If Mozilla's answer is 'yes', they don't need to bother with the rest of the questions.)

  2. Does Mozilla believe that it had meaningful informed consent from people to install the 'Looking Glass' addon? If so, how does it believe this consent was obtained?

    (I don't think people believed they were consenting to this when they left 'Allow Firefox to install and run studies' selected, which means that at a minimum it cannot be informed consent.)

  3. How did Mozilla allow this to happen without meaningful informed consent?
  4. How will Mozilla prevent this from happening (without meaningful informed consent) in the future?

Up until now, I and likely many other people believed that Mozilla's answer to the first question would be 'no'; Mozilla did not believe that it had the right to yank around our Firefox installs without our permission. Unfortunately, based on Mozilla's public reactions so far, the actual answer appears to be 'yes'. Mozilla is not sorry that it shoved an addon down people's throats without their consent; Mozilla is sad that people are upset about it. For example, from another quote from Mozilla's marketing people:

[...], we heard from some of our users that the experience we created caused confusion.”

This is mealy-mouthed corporate PR weasel speak and may be freely translated as 'we're sorry that we got caught'.

I didn't title this entry 'some questions for Mozilla', because while they are questions for Mozilla, Mozilla is not going to answer them just because I wrote them; I'm an insignificant blogger, not someone with a voice powerful enough to reach Mozilla's ears or get its attention. It is my hope that someone with enough volume and power to get Mozilla's attention does ask something like these questions to Mozilla, and perhaps being explicitly confronted with the first question will change Mozilla's direction.

(I would say 'wake Mozilla up', but I don't think the people in charge of Mozilla are asleep, exactly. They're just indifferent.)

If Mozilla's answer to the first question is 'yes', as it implicitly is currently, then I must take back some of what I said yesterday about not switching to Chrome. Chrome is certainly not better than Mozilla here (Mozilla still has nominal principles about user empowerment, privacy, and so on), but there may be pragmatic reasons that make Google less likely to do this sort of thing with Chrome. But how I see that is something for another entry.

(I don't currently intend to switch away from Firefox 56, mostly because I don't believe there are any good alternatives for me.)

MozillaSomeQuestions written at 01:16:37; Add Comment

(Previous 10 or go back to December 2017 at 2017/12/15)

Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.