Writing my first addon for Firefox wasn't too hard or annoying
(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
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
up to me, which made me a bit worried about needing to play around
with regular expressions and string manipulation and parsing URLs,
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.
There are a couple of things about your addon
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
(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
.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
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.)
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.)
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
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.
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.
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.)
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
(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:
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>
(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.)
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.
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
that match a specific pattern.)
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
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
- 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).
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.
Some early notes on using uMatrix to replace NoScript in Firefox 56
(Since I'm also using uBlock Origin, I turned off all of uMatrix's site blocklists as just being duplication.)
(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 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.)
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
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
Apparently setting the
falsemay 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).
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.)
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.
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.
- 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.)
- 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.)
- How did Mozilla allow this to happen without meaningful informed consent?
- 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.)