Fix for disabled add-ons in Firefox Nightly
If you run Firefox Nighly and use add-ons, you may have noticed that some may have been disabled automatically after the latest update of the browser.
When you open the add-ons manager, and then one of the add-ons that has been disabled automatically, a reason is displayed why it has been disabled.
The Dictionary Switcher add-on for instance displayed the following information: "Dictionary Switcher has been disabled since it is not multiprocess compatible".
Basically, what is happening is the following: if an add-on is neither a WebExtension nor multi-process compatible, it is disabled automatically in Firefox Nightly.
Note that this is limited to Nightly, and that other Firefox editions are not affected by this. This is however a foreboding of things to come, as the disabling of legacy add-ons will happen later this year when Firefox 57 gets released to the public.
Mozilla reveals the reason behind the move on the Mozilla Wiki.
The Firefox team is currently focused on vastly improving performance in Firefox 57. Unfortunately, if you have add-ons installed in Nightly that are not WebExtensions, they make performance measurements on Nightly much harder. This is especially true of add-ons that are not multiprocess compatible and use shims.
As a result, we are asking all Nightly users to stop using add-ons that are not multiprocess compatible, or are not WebExtensions. Please bear in mind that these add-ons might stop working by Firefox 57 anyway.
Fix for disabled add-ons in Firefox Nightly
You probably wonder if there is something that you can do about it. And there is, at least for the time being.
- Load about:config in the Firefox Nightly address bar.
- Confirm that you will be careful if the prompt comes up.
- Search for the preference extensions.allow-non-mpc-extensions.
- Double-click it to set it to true.
The add-ons that were disabled automatically after the Nightly update will be enabled on the next restart again once you set the preference to true.
Keep in mind that this preference will be removed in the future, likely around the time that Mozilla will drop support for legacy add-ons. You can follow the tracking bug 1352204 to monitor the development.
Update: To enable legacy extensions in Firefox Nightly, read this guide.
Closing Words
Mozilla states clearly that it implemented the change to get better performance telemetry data. It seems likely that the organization is also keeping an eye on things for another reason: it is a first test balloon to see how Nightly users will react. How many will accept the change, how many will reverse it using the preference, and how many will switch to another version of Firefox or another browser?
Now You: How many of your add-ons would be disabled if you'd run Nightly?
Welp I’ve lost all my add-ons, so I’m kinda pissy about this !@#$%^&* update…
11 out of 14 for my Nightly. I’m gonna miss “Download them all” most.
80% aprox of my various dozens of addons were disabled… AshesFox rules!
About a dozen addons were disabled when I had to restart my Nightly just now. (It was running fine for almost 5 days, so that’s why I’m a bit late to this issue.) Anyway, I have about 50 addons loaded regularly and I noticed right away that a couple of my most used ones were missing. It seems the default value for “extensions.allow-non-mpc-extensions” changed (from true to false) with one of the latest updates. Most addons still work just fine even if they weren’t specifically made for the e10s environment and I hadn’t have any problems with the ones I use now, so there was no question that I had to allow them.
Five addons were disabled:
– ImTranslator
– Popup Blocker Ultimate
– Twitter App
– Web of Trust
– Norton Security Toolbar
Beyond Australis is still enabled but according to the developer not for much longer.
However I have deleted Web of Trust. I’ve overslept the scandal, again. As with Adblock Plus and Ghostery…
2 add-ons were disabled, but one of them I deleted now. Kaspersky Protection was disabled, but thanks to your information it is active again in my Firefox Nightly. I do not use much extensions.
I am curious when we can see the new menu structure in Nightly, as shown in the article about Firefox 57 Photon mock up photos.
> It seems likely that the organization is also keeping an eye on things for another reason: it is a first test balloon to see how Nightly users will react.
I understand it’s speculation, but to what end?
There’s no plans to reverse course and the Nightly tester audience is notably different than the general Firefox audience (they’re much more technical in general for one).
Caspy, I understand that Mozilla won’t change course, but they might delay the switch if they notice that a large enough number of users flips the switch to continue using deactivated add-ons. At the very least, Mozilla will monitor what is happening closely.
Half of my addons won’t work, and most of these haven’t been updated for months, even years, so the chance they’ll be now is exactly zero.
So, if those people who captured Mozilla are trying to corral users into Chrome by lack of a real alternative (which is what it seems), congrats, they’re driving Firefox into a corner and that will put it out of its current misery faster.
But in what respects me, if I’ll have to stick with a browser that doesn’t really suite me, I’ll stick to what I already have instead (i.e.: ie/edge). The essential (ad filter) works, and the (useful) rest, I won’t bother again.
That or as I suspect many will do: just like with Windows Update, stop updating Firefox altogether and no matter what…
“Please bear in mind that these add-ons might stop working by Firefox 57 anyway.”
That is the first time I’ve read Mozilla softening on their hardline stance.
I expect most of my 11 add-ons will not transition.
Greasemonkey I’ll miss; but there are alternatives.
Others are rarely used but still come in handy: Tag Sieve, Markdown Viewer, Mass Password Reset, and UnMHT. It’s likely too much effort for a single developer, if it’s even possible with Web Extensions.
Print Edit is used frequently, and now it has a Web Extension version – YAY! I can’t wait to try it out.
I’m still using Htitle to get tabs in the titlebar in Linux (until https://bugzilla.mozilla.org/show_bug.cgi?id=1283299 is finally done). It’s abandoned, but seems to work fine in e10s if I force it.
It would be as nice as a surprise if the extensions.allow-non-mpc-extensions setting remained included in FF57+ versions.
Here 69 add-ons of which 4 are Webextensions and 26 reported as [MultiprocessIncompatibleExtensions]
None of the 26 are Webextensions so, to answer the question, I’d lose at this time …. 26 add-ons.
But between now and November’s FF57 some of my little fellas might chin up and make their way to Webextensions and e10. Come on, add-ons, just do it! I know, I know for some of them it’ll just be as impossible as a Marine head of France, though cries for the former and joy for the latter.
Thanks Tom. FYI, the section of extensions.ini that you mention is notoriously inaccurate. For whatever reason, it fails to include many installed extensions that are not e10-compatible.
Tom, what is reporting them as [MultiprociessIncompatibleExtensions] for you? Firefox Nightly?
@Tony, [MultiprociessIncompatibleExtensions] is a section of the extensions.ini file located in the user’s Firefox profile.
@Tom Hawack: Despite the Mozilla apologists around here claiming that Mozilla was “striving to include more APIs in order to make sophisticated extensions possible” nothing has come to pass yet. Don’t expect any add-on which changes the UI in a major way or has a major impact on the browser’s functionality to work. Things like NoScript or uBlock Origin are going to work, that’s for sure. Things like Tree Style Tabs, Classic Theme Restorer, Tab Mix Plus… not so much.
And then there is the question of what you would describe as “working”. A severely dumbed-down version of an add-on cannot be called “functional”, really. So if I was you I wouldn’t hold my breath.
Your best bet is probably to stick to Firefox 52 ESR until support for this one runs out, and then to reconsider your options. The chance that you’ll lose a ton of functionality with Firefox 57 or Firefox 59 ESR respectively is approx. 100%.
> Hence why I have already started to use alternatives, namely Waterfox and Pale Moon.
Both one-man shops with uncertain futures. Especially with the phase-out of Cyberfox and a lack of commitment with Fossa Mail.
I wouldn’t put all my eggs in those flimsy baskets, either.
@Sören Hentzschel: The typical apologetic attitude towards Mozilla, nothing new with you. One important add-on will be saved (maybe in a crippled state), whereas hundreds of others will die. Overall a rather pathetic state of things still, which is the point I wanted to make. By the way, I am only believing it for this one when I actually see it…
@Tom Hawack: Nah, don’t expect any surprises from Mozilla. In fact there was a major uproar when they were revealing their Australis plans (sounds somewhat ridiculous compared to what is now being planned), yet they were determined to go through with it anyway. So, knowing their ways, I expect them to do as they have announced regardless of what users or add-on devs say.
Hence why I have already started to use alternatives, namely Waterfox and Pale Moon. When Firefox 52 ESR runs out of support (at the release date of Firefox 61) there won’t be any official Mozilla browser to support classic add-ons anyway.
Furthermore I am not entirely convinced of their Servo plans. For one, I don’t expect Servo to be so much faster when compared to the current Gecko implementation. Provided you have a decent Internet connection modern browsers render sites in 1-2 seconds at most. So whatever speed improvements may be introduced will hardly be visible for the human eye and are thus negligible. However, I totally understand that a new platform could be needed in order to prepare Firefox for the future, especially when it comes to an easier implementation of web standards. The issue I am having with Mozilla is the simultanous dumbing-down of Firefox which seems to go hand in hand with these changes. What use is there for a future-proof Firefox when it is non-extensible at the same time? Anyway, I doubt Servo (or Rust for that matter) will have a major impact on anything as Mozilla hasn’t been the driving force of the web for years. Whatever Google comes up with will be more relevant, regardless whether or not it is actually better on a technical level.
@Appster, your last paragraph exactly resumes my state of mind at this time.
I agree as most often with your analysis but life is often a surprise, even for experts. I am aware that some routines just won’t be able to make their way in Webextensions whatever the APIs but I remain in doubt whan it comes to exactly how many of them hence how many of mine.
Whatever, FF52.1 ESR is the end of a paragraph, the point is to know if I’ll close the book, then, or continue with the next one.I should say “we” considering many must feel confronted to this choice, in the air as ‘Winds of War’ (starring Robert Mitchum, a great TV production of the eighties) …
> Things like Tree Style Tabs […] not so much.
Not true. There is a Tabs API, there is a Sidebar API and there will be an API for hiding the tab strip. So add-ons like Tree Style Tab are possible.
Distill Web Monitor
Self-Destructing Cookies
Open Tabs Next to Current – fixed in beta
3/13
> How many of your add-ons would be disabled if you’d run Nightly?
I do run Nightly and these extensions are disabled.
1. CoLT – CoLT (short for “Copy Link Text”) makes it easy to copy either a link’s text, or both the link text and its URL in a format you specify.
2. Ubuntu Modifications – Ubuntu modifications for Firefox
3. Nightly Tester Tools – Useful tools for the nightly tester.
> How many of your add-ons would be disabled if you’d run Nightly?
1. 1Password.
> How many of your add-ons would be disabled if you’d run Nightly?
Only two of my add-ons are affected and I don’t need these two add-ons.
“How many of your add-ons would be disabled if you’d run Nightly?” – 2 out of 30 (assuming shims are allowed, in which case it would 5)