[dblohm7]

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

[Zak]

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.

[dblohm7]

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

[Zak]

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.

[dblohm7]

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

[Zak]

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.

[sgift]

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.

[account42]

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

[gitaarik]

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.

[cxr]

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

[sgift]

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.

[mod50ack]

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.

[Zak]

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.

[toyg]

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.

[Vinnl]

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.

[dblohm7]

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.

[gitaarik]

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.

[dblohm7]

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.

[gitaarik]

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

[cubefox]

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

[dblohm7]

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.

[cubefox]

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

[JustinGoldberg9]

afaik this is why android chrome never supported extensions.

[rvba]

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

Also I wonder where do those decision makers work now.

[athrowaway3z]

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.

[mod50ack]

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.

[pcwalton]

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

[SheinhardtWigCo]

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

[pcwalton]

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.

[SheinhardtWigCo]

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

[lupusreal]

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.

[JustinGoldberg9]

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

[asadotzler]

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.

[rightbyte]

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.