This is good. Now, all extensions marked by the developer as being compatible with Android are shown on AMO. (If you toggle to Desktop mode, you can actually install any other extension on AMO, too.)
The baffling thing is why this took so damn long. FF for Android supported add-ons from the beginning. That's the best thing about Firefox for Android! They decided to rewrite the UI in 2020, and there were fair reasons to do that. Obviously this required some reimplementation time for extension support.
But they then launched the rewrite of FF for Android with extension support... but hidden. Only a small set of recommended extensions were enabled, and a few were drip-fed over time (that is, added to the list). Thankfully, this included the single most important extension, uBlock Origin, from the very beginning. (The lack of uBO why Chrome for Android is borderline unusable for me!)
But from almost the very beginning, we've also had the ability to activate custom extension collections in Nightly (and in Fennec F-Droid, which is a rebuild of stable Firefox). The vast majority of extensions worked fine for... well, years now.
So why in the world was this delayed the whole time?
I managed the team that did a lot of the integration of web extension support in Fenix, the new Firefox for Android. We were all on the brink of burnout. There was too much work. Unrealistic deadlines. And high expectations. So we decided to only support a limited set of APIs tuned for the most popular web extension. Which were basically all ad blockers if I remember correctly.
Proud of the team to have finally gotten to this point. Miss you all.
Other people may remember this differently. Some things are a bit of a blur. My brain selectively blocks some of this - It was basically an exhausting two/three year crunch to rewrite Fennec as a modern Android app.
That's how I remember it. I was on desktop projects but following closely and the rewrite was a death march and people working on it moved or left along the way too.
We should have listened to Hyatt back in 2003-ish when he basically said of XUL, "it's never gonna be great on *nix or Mac but it's good enough on Windows." Because of solid desktop horsepower growth over the 2000s, we were able to make XUL go for the three desktop platforms pretty well but it should never have gone to mobile and replacing it with a native front end was absolutely the right thing to do, despite the pain.
XUL is not the whole story, though. There was an Android native Firefox before the current Fenix and after the XUL Fennec, and it had Web Extensions, IIRC. From that perspective, that people complained is understandable.
Just want to say thank you for your enormous effort on this. I'm extremely picky about software but Firefox on Android is one of the best pieces of software I've ever used. And I use it every day - probably more than any other app. I still remember how happy I was when youn folks got those adblocker extensions working on mobile. Thank you.
It sounds like they intentionally under-provisioned you all to draw it out, which isn't surprising given their biggest source of funding is Google, and the last thing Google wants is ad/tracker blocking, privacy extensions, and, well, a major reason for people to set their default browser to 'not chrome'.
Lord knows there's enough money floating around that place.
What a shame - but thank you. Hopefully plugins come to Firefox for iOS some time.
Considering uBlock Origin was the first extension to work (and, from what I understand, they worked extra hard to ensure it works), I doubt that's the reason.
That could be a power struggle. I.e. some Google loyal PM sabotaged the extension feature, but quoting the poster above, the devs worked around it by doing a partial implementation to support adblockers, foiling the plan :)
I am desperately looking for an extension that takes over godawful js video players and gives something standard. Some have click to pause, some forward backward, all don't have volume control.
Might not be exactly what you are looking for but I use an extenstion [0] to open videos in an external video player (mpv). That way the controls are consistend and playback does not depend on where I browse.
mpv uses youtube-dl (or yt-dlp) to fetch the stream URLs and that supports many sites.
> The baffling thing is why this took so damn long.
I'm surprised it's baffling in a community of developers and other IT professionals.
It's not baffling to me that two significantly (wholly?) different applications on different platforms and form factors would require quite a bit of work to both be generally compatible with the same third-party software via the same API - and all while maintaining the same compatibility with another application, made by another company, completely outside Mozilla's control.
And it needs to work reliably enough to release to a world of developers - of every skill level, motivation, writing every kind of software (within the domain of browser add-ons) - with confidence that it will work for them and users.
And you need a way to maintain all that over the long term.
Firefox android extension support went from "all" to like "5 chosen ones, but we'll enable all of them very soon" in mid 2019. How and why those were handpicked, who knows, clearly extensions weren't enabled by supported functions at the time. In the usual mozilla fashion that "very soon" turned out to be multiple years.
Importantly, during this entire multi-year gap, nearly all of them worked just fine but it was gated behind an AMO account for... I don't know what reason.
If it was just an experience issue because like 5% failed weirdly or had bad performance but they couldn't validate them all: that's basically fine! Hide it behind an about:config flag! The AMO requirement was a privacy-invading piece of nonsense that had no business existing.
Again, it's easy to imagine answers to these questions and to grasp what is happening. Instead people choose to play the sport of tearing things down, no matter the effect on the people involved, Mozilla, the open web, etc.
Again, Mozilla had a long time to answer these questions (if they had a good answer). If you leave people to imagine things then don't be surprised if they don't follow your PR-sanitized version of events.
If mozilla cared about the open web they would immediately distance themselves from Google and reallocate funding from their CEO's family to things that actually matter for their mission.
For those who are wondering, I _think_ AMO is supposed to mean "addons.mozilla.org" although neither the author of the article nor this comment define the acronym.
AFAIK it was because firefox for android was on a slightly different codebase than desktop firefox, and thus had supported a different set of webextension apis. The user contexts api (container tabs) was missing entirely, for instance.
It was more complicated than that. Yes, GeckoView needed a separate WebExtension implementation, but that work was pretty much at parity with Fennec (the previous Firefox for Android that supported more extensions) when I left in 2021.
It was a product management decision that held off on more complete WebExtension parity with desktop, as well as any artificial limits as to which extensions were supported in release.
Can you elaborate on the product management motivations?
It seems to me projects like Iceraven demonstrated years ago that a great many extensions were usable without any changes. Why not just slap a "here there be dragons" warning on untested extensions and let users have at it?
To be clear, I'm not asking you to justify decisions you didn't make, just to provide some visibility into the process if you can. Mozilla was pretty opaque about it.
> Why not just slap a "here there be dragons" warning on untested extensions and let users have at it?
We essentially had that as part of pre-release builds. Same with about:config.
The argument we'd then hear from people is, "but I want the stable channel with the 'here be dragons'" stuff. The reality is, though, that the "here be dragons" stuff probably affects stability more than running beta does anyway; people who shat on us for that wanted to have their cake and eat it too, and it just doesn't work that way.
My follow-up question then is why treat mobile significantly differently from desktop? Stable desktop Firefox has about:config and access to horribly broken extensions. Perhaps some would argue that it should not.
It comes down to the high-level architecture of Gecko.
Gecko is not just a web engine; it is in many ways an entire application framework. Gecko inverts control such that it implements the entire main event loop of the application. Desktop Firefox is essentially one big privileged HTML+JS application that happens to embed a non-privileged browser iframe within it. about:config governs settings around everything in this framework.
Now let's look at Android: the modern architecture of Firefox for Android is that of a native Android app that embeds Gecko similarly to a WebView, albeit a much more powerful one (GeckoView)[1]. Many parts of GeckoView's implementation need to deal with reconciling the "Gecko as app framework that controls the universe" paradigm with the "Gecko as a lowly Android View rendering into a graphics surface" paradigm. about:config is still important, but it only affects the Gecko part, not the native app part.
For GeckoView to work correctly, many about:config settings must be set to very specific values -- the free-for-all that is about:config on desktop could actually break an instance of Firefox on Android. This is particularly fatal to an app when run on a non-rooted phone.
Thanks for the more technical explanation. Explanations for restricting about:config I've come across before didn't make it clear that Firefox for Android is a substantially different design from Firefox for desktop that's easier to break in that way.
I cannot speak for Mozilla, but just from my gut feeling: That probably got grandfathered in and since people are used to it for a "long time" no one would change it. But if Firefox was rereleased today I wouldn't bet on it being there. Expectations have changed.
Yes, people have come to accept shitty software. You'd think that software developed for the public good would try to be better though and at least retain the old standards for power user tools.
What? You are saying that the `about:config` feature only exists in Firefox for historical and backward compatible reasons? And Firefox rather actually doesn't want to provide people the ability to easily override advanced configs? I think this feature is one of the things that sets Firefox apart from other browsers, that you have more control if you want it. And I am saddened it's also never been implementes in Firefox Android.
> `about:config` feature only exists in Firefox for historical and backward compatible reasons? And Firefox rather actually doesn't want to provide people the ability to easily override advanced configs?
I don't think it's unfair to say that that's basically correct.
I say that I wouldn't be surprised if they didn't implement it in non-dev, non-nightly versions if they made Firefox again today. But I know nothing about what the thoughts of Mozilla or the people working on Firefox are. It's just an idle speculation.
Pre-rewrite FF for Android supported about:config. Actually, Fennec F-Droid and the Beta version of Firefox support it just fine, too. It exists in stable FF but is cordoned off for some reason.
Firefox for Android was around for 8 or 9 years with full support for extensions and access to about:config. I think that's a long time in this context.
Probably fear that bad extensions would tank performance, tarnishing the reputation of the overall browser. Now that such reputation is more or less established (i.e. people use FF on Android without big problems, it's not considered particularly slow etc), they can dare a bit more.
I believe it's that, and that with extensions living in their own processes, Android can at any moment decide to kill it (like it can do with any mobile app). With the changes required for Manifest V3, extensions are able to deal with that gracefully, rather than causing a deluge of bug reports.
That's part of it, for sure... at the time I was still there, Gecko's extension process did not have the capability of recovering from termination. But that just meant that we couldn't run them in a child process, not that we couldn't run them at all. Of course, then you have security considerations, which no doubt could have factored into the product decision.
It's common practice these days in Android apps to request the user to turn allow the app to run on the background, opening the necessary Android settings page if you want to grant the app access to this. If an addon needs that feature, the app could request this for the addon at moment of installation.
I think you misunderstand what I'm saying. Modern browsers try to host their extensions in a special sandboxed subprocess. At the time I was there, the code in Gecko that hosts sandboxed child processes was completely unable to deal with that host process being terminated; ie Gecko could not recover from that. It has nothing to do with Android settings.
You can fix that in other ways that doesn't block access to all extensions. Like yeah even just a checkbox to enable experimental extension support like "[] I understand Firefox can become slower from unsupported extensions I install".
This is speculation based only on press releases but:
- Google pays Mozilla more than 400m per year.
- Its in Google's interests to not have good Firefox add-ons. (For both Ads and Chrome's market share).
Google's negotiator could easily added some incentive for Mozilla's management to set the focus somewhere else.
In fact, given what Google's team is likely earning, they wouldn't be doing a good job if Firefox's mobile strategy wasn't discussed before signing such deals.
Firefox for Android had add-ons before, and even during the past few years, they're fully supported the collection of recommended add-ons, including uBlock Origin from day one. So I don't see how it could be about preventing ad blocking.
The idea that Google has some secret underhanded deal with Mozilla to sabotage Firefox comes up here repeatedly and makes no sense. If Google wanted to prevent ad blocking on Android it would be much simpler to just ban ad blockers from the Play Store outright.
There is a much simpler potential explanation for such a product management decision. Suppose Mozilla determines that 90% (made-up number) of users want addons because they want uBlock Origin. It then seems sensible to prioritize that addon and not others when determining how to spend limited engineering resources. Reasonable people can of course disagree with that decision, but there's no need to bring conspiracies into it.
(NB: Even though I worked at Mozilla I have zero insight into this particular issue; it's entirely speculation.)
> The idea that Google has some secret underhanded deal with Mozilla to sabotage Firefox comes up here repeatedly and makes no sense.
That idea is supported by recent disclosures revealing that Google paid or attempted to pay Activision, Aniplex, Bandai Namco, Bethesda, Blizzard, Com2uS, EA, King, Mixl, Niantic, NCSoft, NetMarble, NetEase, Nexon, Nintendo, Pearl Abyss, The Pokemon Company, Riot, Square Enix, Supercell, Tencent, and Ubisoft to influence each company’s product roadmap. [1]
I think it makes sense that they would attempt to exert similar influence over an entity whose continued existence is entirely dependent on revenue received from Google and (ostensibly) competes with one of their of their strategic initiatives.
Sure, it’s speculation, but it’s not wild speculation.
From a skim, "Project Hug" seems like it was a deal to keep games in the Play Store. That is a far cry from some kind of weird deal to sabotage a competitor's product.
Why does Firefox still not ship with adblocking by default? Other browsers do, and Firefox touts itself as a privacy browser yet lacks this important defaut. Advanced users can install adblocking themselves, but having it on by default would draw in new novice users.
I already know the answer; it would have to whitelist Google or Google would stop paying Firefox to be the default search engine. And if it whitelisted Google, that would only confirm what people say about Firefox being a pet on Google's leash. All the denials of this are laughably unconvincing, people know how the money flows.
This is just silly. Firefox on Android has had uBlock Origin, the world's most effective ad blocker, since day one. But sure, go invent conspiracies rather than do a little research.
Mozilla isn’t an independent entity and hasn’t been for some time now. Sorry, but if one company is responsible for 87% of your revenue and your CEO receives a $7 million salary, then they are a puppet and therefore so is the entity as a whole.
I won’t be surprised if at some point in the future we learn that Google had a discreet veto over any aspect of Mozilla’s software roadmap, as a condition of the money faucet continuing to flow.
Google is known to make underhanded deals (just Google “Epic v Google” for details); they provide the funding that allows Mozilla to exist; and a Firefox with a capable extension model is indeed a serious threat to Chrome’s marketability and Google’s strategic interests.
Given all that, it’s difficult to believe that a key differentiating feature was legitimately starved of resources for a decade.
The biggest blocker for me is font kerning on canvas elements being broken. That causes Google Docs to render terribly which makes it practically unusable. https://bugzilla.mozilla.org/show_bug.cgi?id=1445596
Another one is favicons not being stored/synced across browsers. This causes me to have a bookmark toolbar with entirely the same default icon without any text. (I prefer them as icons, fits more stuff there). I don't have this problem with Chromium based browsers. https://bugzilla.mozilla.org/show_bug.cgi?id=428378
And a chunk of Mozilla's funding going towards social justice related projects, as much of the organization has been co-opted by social justice types.
As was stated in the article[1], close to half a million dollars was spent on a social-justice related organization, the Mackenzie Mack Group.
“[Mckensie Mack Group] is a change management firm redefining innovation in the white-dominant change management industry.”
In the article it also says " While The Lunduke Journal does not like to delve too deeply into the Political Woods (tm), it should be questioned why so much money — possibly millions of dollars donated by individuals who thought they were supporting a web browser — is being funneled into highly political organizations that seem to have no involvement with the World Wide Web, Web Browsers, or any related standards. "
That article actually shows that Mozilla spends most on software development.
It does have a lot of administrative overhead that it could do without, instead of laying off engineers, like they did. But the article itself is trash, due to complaining of $892,000 worth of expenses that seem dubious, in an organization that makes 500 million per year, which paints a certain kind of picture that's disingenuous.
The article may be trash as you said, but Firefox doesn't disclose how much they spend on developing Firefox web browser. Everything is lumped under "software development", and that's only half of their annual budget, Firefox certainly doesn't get the most of the budget.
If they spend most of that $200 million on Firefox annually and we have abhorrent text rendering on canvas elements for YEARS, something's seriously broken there.
1. they wanted an Apple-level of verified review process for AMO, because the Chrome store and even Android app store have problems with malicious content.
2. This costs money.
3. They didn't want to open a free for all because they didn't know exactly how to go about solving 2. yet, and if they introduced some payment system then it would be easier to do from a clean slate, without an AMO full of existing extensions to somehow grandfather through.
As said before, this is fully unfounded and probably unfair speculation. I like it more than the 'google conspiracy against adblockers' though because Mozilla's motivations in this case are quite reasonable and can be taken in good faith. Keeping credit card skimmers out of AMO at the cost of restricting access to 'Firefox Pro'/'AMO Pro'/author-pays would honestly be quite a good thing for Mozilla to consider imo.
In any case it's great to see them allowing things now!
The baffling thing is why this took so damn long. FF for Android supported add-ons from the beginning. That's the best thing about Firefox for Android! They decided to rewrite the UI in 2020, and there were fair reasons to do that. Obviously this required some reimplementation time for extension support.
But they then launched the rewrite of FF for Android with extension support... but hidden. Only a small set of recommended extensions were enabled, and a few were drip-fed over time (that is, added to the list). Thankfully, this included the single most important extension, uBlock Origin, from the very beginning. (The lack of uBO why Chrome for Android is borderline unusable for me!)
But from almost the very beginning, we've also had the ability to activate custom extension collections in Nightly (and in Fennec F-Droid, which is a rebuild of stable Firefox). The vast majority of extensions worked fine for... well, years now.
So why in the world was this delayed the whole time?