Oh, and since they load it like this, their code ends up as dirty pages in memory instead of having on-demand paging from shared objects on the filesystem either in the apk (uncompressed) or in the directory of automatically extracted libraries / executables (compressed in apk).
Conversation
Transmission of an apk is compressed so having a library uncompressed in the apk like Chromium doesn't waste bandwidth. The apk uses a bit more space on the device, but less than having it both compressed in the apk and extracted alongside it. Firefox's design choice is terrible.
1
1
Firefox (fennec) is in semi-maintenance mode -- you should check to see whether Fenix has the same behavior and report it as an issue if so.
github.com/mozilla-mobile
tools.taskcluster.net/index/project.
2
1
2
Is this still Firefox but just replacing the mobile integration with something new?
2
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.
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
Show replies