Hacker News Reader

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.

Thank you to all the Firefox on Android developers! Ads on mobile Make the platform basically unusable without blockers.

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 :)

You don't need to invent some spy story fiction to explain software cost under-estimates and delays.

Not everything is a conspiracy

Sure. Obviously I don't know why.

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.

[0] https://addons.mozilla.org/de/firefox/addon/send-to-mpv-play...

Nope you are making up stories.

If you don't have manpower for a rewrite... then why rewrite?

> 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.

I'm impressed Mozilla!

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.

Privacy-invading requirements that delay implementation of plugins that would enable plugins providing better privacy and ad-blocking functionality?

Hmmmmmmm, now what major Mozilla sugar daddy would be interested in that /s

Why the sarcasm tag?

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.

You may find some clues as to why they don't want to interact with people like you in your very own post!

It's not just that; their other "unstable" release, "Firefox Nightly", didn't have this limitation.

The extensions worked just fine on Android before an update a few years ago broke them. I can finally use extensions that I've been missing for years.

Did you read past that sentence you quoted?

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.

I was also somehow aware of this acronym. Turns out the about page of Mozilla's add-ons page also uses it[1], so it's "official" so to speak.

[1]: https://addons.mozilla.org/en-US/about

Yes, indeed, AMO means addons.mozilla.org

The article currently does define it, but maybe that was changed.

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.

(I used to work on this stuff)

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.

[1] https://geckoview.dev

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.

> 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.

> It exists in stable FF but is cordoned off for some reason.

See my comment at https://news.ycombinator.com/item?id=38657971

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".

That fear was obviously unjustified. Extensions that would tank performance would have gotten bad user ratings.

That's assuming that you know that the extension is the cause. A bad extension doesn't always kill perf as soon as you install it.

Surely enough people would have figured it out to result in bad ratings.

afaik this is why android chrome never supported extensions.

Probably wanted help chrome keep its market share while keeping firefox insignificant.

Also I wonder where do those decision makers work now.

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.

[1] https://www.theverge.com/2023/11/9/23954107/here-is-the-full...

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.

Keep games exclusive to the Play Store = block/sabotage Play Store competitors

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.

It's not unusual. MSFT funded apple mainly to not appear to be a monopoly.

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.

That can just be an indication that the conspiracy failed as some internal people countered it by a hack.

I.e. having unlock origin available at launch might have been a conspiracy.

E.g. the yes men types tried to sabotage it, while the unsung heroes did it anyway.

Use kiwi, is Chrome based and has full extension support

... and even Developer tools. I have been using it as my daily driver since the Firefox mobile dropped extensions and about:config years ago

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.

My crank unevidenced theory is that

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!