Is this still Firefox but just replacing the mobile integration with something new?
Conversation
It throws away their Android app code and replaces it with a more modern codebase written in Kotlin without bad legacy decisions. It uses Gecko via a new modular library aimed at offering an alternative to the Android WebView.
wiki.mozilla.org/Mobile/GeckoVi
1
1
Not so sure "Because GeckoView is a standalone library that you bundle with your application, you can be confident that the code you test is the code that will actually run." is a feature though. Automatic WebView updates without app involvement + always on sandbox is great.
2
I'd say having webview at all is a misfeature. Non-browser apps should never be embedding browsers; this should be grounds for ban from store. It's essentially phishing for credentials.
1
Most Android browsers are WebView frontends. Firefox's own Focus browser started out as one, but now they're moving to using GeckoView as a replacement for the WebView primarily as a dogfooding thing. The WebView itself isn't really a browser, just a web rendering engine though.
1
Each app's usage is a separate instance. It's usually a shortcut to cut costs by avoiding the development of a proper native app. Instead, they reuse web development work for portions of the app on both Android and iOS. There are whole app development frameworks built on it.
2
A use case that I had for it was to build a PDF Viewer leveraging the hardened Chromium rendering stack. It has a fully static set of code and style properties (enforced by CSP), so RCE would need to happen via the small subset of the browser rendering engine within the sandbox.
1
1
As opposed to using one of the many native PDF rendering libraries written in C like libpoppler, along with much more directly exposing the GPU stack, font rendering stack, etc. which are much less hardened than the way it's exposed in Chromium since it's for untrusted content.
2
I think that's a decent approach to handling extremely complex document formats. Rather than having a separate native rendering stack for each one, it's more than fast enough to convert them on the fly to a web page, without actually generating / running any untrusted JS or CSS.
1
I was very disappointed that Mozilla abandoned github.com/mozilla/shumway because it could have become a great way of handling archived Flash content like old games within a browser without additional attack surface. Instead people will keep using Flash long after it's unmaintained.
1
There's an Archive Team project for this kind of content, but they depend on using Flash Player blob and others: bluemaxima.org/flashpoint/. Needing a Windows virtual machine to run some blob is not exactly on par with having open source emulators for old game consoles, etc.