It's worth pointing out that this isn't truly "getting past it". It's still locked to Mozilla's add-on store (preventing you from testing or manually loading extension bundles) and all you're really doing is switching the collection that Fenix loads the extensions from to one you control instead.
One of the bigger reasons to use Fennec instead (the old Firefox Android browser, still maintained as a community fork) for me has been the fact that you can also load in the XPI files yourself, which is needed for a few FOSS extensions that aren't submitted to the Firefox Add-On Store due to one reason or another.
Hmm I use F-droid Fennec daily, and it has the same whitelist of available extensions as regular Firefox. I don't see how to add your own, unless you go through the hoops of enabling debug mode (described elsewhere in another comment)
It was basically a complete rewrite. Mozilla moved from a bundled browser + UI to a GeckoView component with a browser UI on top.
I'm not sure anyone else actually uses GeckoView. I only know about it because their argument for disabling about:config is that users could mess up the bindings between GeckoView and the browser, forcing you to clear the browser's data to get it working again if you mess up the internals.
The old browser definitely could've used some refactoring but after the rewrite almost every feature that made Firefox interesting disappeared. They also changed how user-installed certificate authorities are handled (if you, as a user install your own CA, you need to tap the Firefox logo in the settings seven times to open up special secret settings and enable loading the CA in there).
Firefox currently has two things going for it: their tracking prevention being built in, and a few useful addons. If you don't use those or don't care too much about them, you should switch to Chromium (I recommend Bromite as an alternative, which has ad blocking built in and even rudimentary user script support without addons) because Firefox is a lot slower in comparison.
Completely new codebase yeah. The old codebase is known as Fennec and is directly based on Gecko (the browser engine that powers desktop Firefox). All the same advantages. The UI wasn't excellent, but it did the job perfectly well.
The new codebase is known as Fenix and is instead based on GeckoView which isn't an actual browser but rather an library version of Gecko that is intended to replace Androids own System WebView (it was first used in Firefox Focus which was this tiny trackerblocking microbrowser that they offered).
The difference sounds tiny but it feels just... way clunkier to use and there's a bunch of features missing since a WebView browser isn't made with those in mind the same way a regular browser is.
There's just... loads of features missing or not available and the team working on Fenix is blatantly either mismanaged or underfunded. It's so feature-poor that you still can't actually set your homepage to a URL[0] among many other bugs and missing features. It appears to have gotten so bad that they moved the entire issue tracker over to Bugzilla and moved the repo to a new GitHub repo to hide just how feature poor this browser is.
Firefox Fenix is terrible, has been terrible for the past 2 years and I don't understand why they're still developing it instead of shoring up Fennec properly.
> but rather an library version of Gecko that is intended to replace Androids own System WebView
Not literally, though. Yes, the idea of packaging up the rendering engine inside of an Android library with a proper Java API was likely modelled on the implementation of the system web view, but I don't think that offering a literal drop-in replacement was ever the goal. Literally replacing the system web view is impossible anyway unless you're building a custom version of Android, and even just offering an API-compatible replacement (which would mean probably having to emulate quite a bit of Chromium/Blink-specific behaviour with Gecko) seems of dubious value [1] compared to the additional effort required for building such a thing.
> there's a bunch of features missing since a WebView browser isn't made with those in mind the same way a regular browser is.
I think that's not so much the Webview-inspired technical design, but simply the fact that Firefox on Android always seemed chronically under-staffed. Even with the old Fennec codebase there were some comparatively and surprisingly major bugs and missing features (didn't remember your scroll position if the memory pressure evicted either background tabs or the whole Firefox process, under memory pressure session history would stop recording entirely for tabs that had been unloaded once [2], you couldn't re-order tabs in the tab list, and quite a few more) that remained open for sometimes years and were in quite a few cases only fixed because of outside contributions.
So then they went and did the Thing You Should Never Do [3], i.e. throw away the existing codebase, which of course meant that all and every little feature and UI nicety that finally got added throughout the years (and sometimes only because of outside contributions) got thrown out, too, and had to be re-implemented from scratch. And what with the Android browser still not being all that generously staffed and having to re-write the whole browser from scratch, it means that any progress beyond the MVP state will necessarily be slow and very intermittent.
> Firefox Fenix is terrible, has been terrible for the past 2 years and I don't understand why they're still developing it instead of shoring up Fennec properly.
The problem was that due to being chronically under-staffed (and also because of Fennec's design with a native Java Android UI [4] meant that you got at least the UI responsiveness benefits of multi-process even without actual Gecko-side multi-process capability), they never got around to doing the whole work of making Gecko on Android multi-process ready and only finally did it as part of the GeckoView/Fenix total rewrite. Given the time that has passed since development on Fennec stopped (and as far as Gecko was concerned, it stopped even earlier because they eventually shunted off Fennec to the ESR branch, which coincidentally meant putting a relatively fixed termination date on Fennec, regardless of how good or bad Fenix would be coming along one year hence +/- a few weeks [5]).
Much as I'm unhappy about Fenix and nostalgic for Fennec myself – if you somehow were able to drum up sufficient manpower for making a real dent in the bug backlog, I suppose that at this point it'd be more efficient finally re-implementing all those missing features back into the Fenix codebase, rather than attempting to get the old Fennec codebase working with a current Gecko build again.
[1] Shipping a custom browser engine (i.e. Gecko) along with your app immediately bumps your APK size by dozens of MB, so unless your app is actually a browser itself, you probably need to have a really special use case and be quite desperate to start considering that option instead of using the system web view which comes at no size penalty.
[2] Either the Firefox developers themselves didn't actually use their browser that intensively, or maybe they all had phones with much beefier specs and therefore never experienced the behaviour on a memory-constrained device. That particular bug got introduced in Firefox 16, got its first bug report for Firefox 24 and amassed seven duplicates before it was finally fixed in Firefox 46, but even that only because I got so fed up with it that I finally investigated and then fixed the issue myself.
Personally I'm not complaining that much about that turn of events, because it got me starting to contributing to Firefox for a while which was nice as a hobby, plus I got an invitation to the San Francisco all-hands out of it, which was nice, too (both meeting the Mozilla developers, as well as the trip itself), but for the management of the whole Firefox on Android project itself it doesn't speak quite that well…
[4] The very first Firefox on Android actually did use a HTML/XUL-based interface just like Desktop Firefox does, but they found that on a phone the performance of that approach was terrible enough that they decided to rewrite the UI as a native Android app (codename "Native Fennec"), which then became Firefox on Android until version 68 and the replacement by the Fenix codebase.
[5] I suppose in a real pinch they could have extended the life of the 68.x ESR branch a bit more, but only if Fenix would have been in a really catastrophic shape at that point.
> It appears to have gotten so bad that they moved the entire issue tracker over to Bugzilla and moved the repo to a new GitHub repo to hide just how feature poor this browser is.
The move to Github with Fenix probably happened because all the cool kids are hanging out on Github these days and they were hoping to gain some additional outside contributors that way. On the other hand, while Github's UI is in some ways possibly a bit slicker and more polished than Bugzilla's, Github's issue tracking is still lacking some notable features that are present in Bugzilla, like proper dependencies between individual bugs. Plus development of Gecko and GeckoView still happens in Bugzilla, so while using Github for Fenix might make things easier for outside contributors, it also introduces some additional friction for Mozilla's own developers.
As for the repo move – from what I remember around the time that the whole GeckoView thing started, they (or at least certain product managers) were dreaming of being able to develop figuratively (or maybe even literally) dozens of little special-purpose browsers along the lines of Focus. Like one special privacy browser (i.e. Focus), one special browser for watching videos, one for… I can't remember actually, but maybe for online shopping, one for doing "research" or something like that, and so on, and so on, and so on.
That's why the old Firefox actually got split up not just two-way, but actually three ways: GeckoView (Gecko packaged up with a proper Android API instead of the sprawling ad-hoc API in browser.js), Android Components (common UI components for web browsers as another separate library) and then the actual browser itself (because like I said the original idea was to have dozens of separate little browser apps, so they wanted to have as much re-usable code as possible – not just the browser engine itself, but also any other components that would be part of the native Android app – things like the URL bar, tab management, downloads, menus, sync, etc. etc.).
It's an admirable goal, but it also introduces quite a bit of additional friction – instead of building the browser in one go, you now need to build three separate projects. I suppose for pure Android developers it's nice not having to directly deal with Gecko [1], but if you're doing things that straddle those component boundaries, it's rather annoying. You have three separate repositories that you need to keep in sync, you need to wrangle three separate builds, when landing new cross-component features you need to land them across those separate repositories in the right order and with the right timing, Gecko development is still tracked on Bugzilla while the two Android repositories used to use Github… [2] And what with the additional split of even the Android app into Android Components and the actual app, even pure Android developers who didn't work on Gecko/GeckoView couldn't entirely escape this additional friction.
And of course (YAGNI was true this time), Mozilla never really got further than building the two browsers that are existing even now (Focus, which still seems to be hanging on, as well as the main Firefox itself [3]), so I guess that ultimately they themselves decided that having two separate repositories (or three, if you're counting Focus, too) wasn't actually worth the hassle, so they decided to merge them back together again in order to make the developer experience more seamless.
[1] Though Firefox has been able to build in "artefact mode" for quite a while now (definitively pre-dating the Fenix rewrite), where it'll simply download a Gecko build from Mozilla so you don't have to compile the C++/Rust code yourself if you don't have any intentions on making any changes in that area. So from an Android developer point of view there's not much of a difference between building the old Firefox for Android with an artefact build, or building the new Firefox with a ready-made GeckoView package, though I suppose the new systems allows you to skip some "Mozillaisms" that are still required for building the full Firefox repository even in artefact mode, plus of course you no longer have to download the whole large mozilla-central repository.
[2] Apart from the general annoyance of feeling that Spolsky was definitively right and throwing out the whole old codebase was a mistake, this was another reason why I stopped contributing to the frontend bits of Firefox on Android – I used to contribute both frontend and backend bits, and in conjunction with the general annoyance about the direction being taken, suddenly having to deal with three separate repositories didn't feel like fun any more.
[3] Okay, so there was Firefox Rocket, too [4], which was supposed to be some sort of lite browser for developing countries, but with the release of the full new Firefox it was discontinued again. (And shipping it with Gecko(View) instead of using the system web view would have definitively taken it out of the "lite" category, too.)
[4] And the "Reference Browser" I guess, but that was only ever intended as a demo project for Android Components and possibly to also aid in debugging without having to spin up a full Firefox for Android build, or before the new Fenix-Firefox was even in a really useable state.
I've landed on using the F-droid build instead of Nightly. That also allows custom extension collections, and I believe Mozilla's attitude was that they get more telemetry for Nightly as they consider that an opt-in somehow (or at least they did for the desktop app).
