4 ms·

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 ex

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.

asddubs 4y ago
what's the difference between the old and new firefox android browser? is it a separate codebase? different UI?
- noirscape 4y ago
  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. [0]: https://github.com/mozilla-mobile/fenix/issues/7551 https://github.com/mozilla-mobile/fenix/issues/7551
  - iggldiggl 4y ago
    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.
- jeroenhd 4y ago
  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.
2h 4y ago
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)

asddubs 4y ago

what's the difference between the old and new firefox android browser? is it a separate codebase? different UI?

noirscape 4y ago
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. [0]: https://github.com/mozilla-mobile/fenix/issues/7551 https://github.com/mozilla-mobile/fenix/issues/7551
- iggldiggl 4y ago
  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.
jeroenhd 4y ago
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.

2h 4y ago

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)