Part 1 due to comment length: > but rather an library version of Gecko that is intended to replace Androids own System WebView Not literally, though. Yes, the

Part 1 due to comment length: > 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… [3] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... [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.