WebView -> GeckoView Migration Announcement

[mazzz1y]

This is an announcement for all current and future Peel users about the browser engine change starting with the next version of Peel, which will be released as v0.30.0.

Peel started as a hard fork of Native Alpha, using its ideas and core implementation. After looking deeper into the app architecture and its design, it became clear that using WebView to render custom web pages was a hacky approach with many limitations, and it was not secure. Its data isolation is also implemented using workarounds, which is not reliable and limits how many web apps can be opened at the same time.

WebView was meant to be used only as a wrapper for small, trusted web pages, and not for browser flows that open third-party sites.

Here are some other issues I found

• Media controls and background media playback are not native supported. Currently, this is implemented with dirty JavaScript injections.
• Pull to refresh works badly and cannot handle pages with iframes or complex structures. It can trigger when the page is not at the top and interfere with in-site pull actions.
• Context menu handling is hacky, and getting the title of a link requires dirty JavaScript injections.
• It cannot handle complex JavaScript downloads. See: Issue: Downloads not working #7
• It is not possible to properly apply privacy settings. Disabling local network requests, WebRTC leaks, and other protections should be supported in Peel, because the idea is to provide isolated web apps with minimal permissions.

Because of this, I do not see any reason to continue supporting this approach. As a solution, I chose to migrate to GeckoView, a library developed and used by Mozilla. It gives us full access to the functionality that Firefox has. This will be a fully refactored app with the same UI/UX, and the upgrade will keep all web apps, groups, and settings. Users should not notice big differences.

The issues users should know before migration are:

• All web app data will be reset after migration, including website cookies and storage, which means you will be logged out of your web apps
• Because Peel will include its own browser engine, the app size will increase and be similar to Firefox, around 80 MB.
• Peel will be split into multiple APKs for each architecture (arm64, armv7, x86).

Always back up your data first to keep your web app list in case of failures. Peel is still an early-stage app, developed by one person, and it has limited testing, although I use it a lot.

Tagging known Peel users for notification: @JonnyTech @elpendor @WilliamKimball0 @BrockTM

[VasilKotsov]

Hello, I using this wonderful app from the beginning of its development and I really like it. I have an idea, but I'm not have an expertise to implement it. Is there any way of implementation of uOrigin like extension the same way as Firefox?

[mazzz1y]

Support for Firefox Mobile (including uBlock Origin) extensions can definitely be added and will be implemented after stabilization

[mazzz1y]

Support for extensions is now available in v0.31.0

[JonnyTech]

I started with WebApps then Native Alpha now Peel and the one thing that I liked about all three is that they use the system builtin webview which makes them fast and responsive, especially while starting up.

My main desktop and mobile browser is Firefox and although I love it, the main problem with the Android implementation is bloat; the startup time can be rather slow and it can be quite sluggish and does have a tendency to crash on bigger pages / sites.

Changing Peel to use GeckoView would be wonderful, I was very excited to see this announcement and I highly anticipate the release. My only concern is resource usage. My phone has low RAM and slow CPU so I fear that this project would change from a lighweight wrapper to a full-blown browser.

Would it be possible to set the rendering engine per site between system webview and geckoview? Or does geckoview do a good job of keeping used resources to a minimum?

I wish you @mazzz1y good luck with this migration as it looks like a major undertaking and am very excited to try it out.

[mazzz1y]

Would it be possible to set the rendering engine per site, choosing between the system WebView and GeckoView?

Realistically, no. This would require too much extra work and too many workarounds in the app's structure.

Or does GeckoView do a good job of keeping resource usage to a minimum?

I can't say for sure because I have not benchmarked it. In my limited testing, I have not seen much difference in performance.

[mazzz1y]

My phone has low RAM and slow CPU so I fear that this project would change from a lighweight wrapper to a full-blown browser.

I also want to point out that if the phone software is outdated, it is not safe to use WebView-based tools, because the browser engine may be outdated and may not have important security fixes. In that case, a bundled Gecko engine is better

[mazzz1y]

Pre-release version v0.30.0-rc3 is ready. It will be released later this week after some testing

[mazzz1y]

GeckoView version released: v0.30.0

[RohitSurwase]

I have few doubts about the migration -

How is GeckoView's software-level session isolation actually more secure than Android's native OS-level process isolation?

Firefox for Android does not even support Multi-Account Containers (MAC). If Mozilla hasn't implemented or stabilized this isolation logic for their own mobile browser, how is Peel enforcing it? Are you relying on experimental or undocumented GeckoView APIs?

Is session isolation really full proof and native to geckoview? Why it is not yet implemented by the Firefox Android browser itself?

How does a single shared GeckoView runtime handle Android's background lifecycle (onPause, onStop) for individual web apps?

[mazzz1y]

How is GeckoView's software-level session isolation actually more secure than Android's native OS-level process isolation?

I never said that the isolation method itself is more secure. I said it is safer overall, because using WebView this way is a workaround. WebView is not designed for this kind of use, and workarounds like this are generally not secure.
With GeckoView, we are using it the way its engine developers intended. It also supports all web features that a browser should support. With WebView, many features require JavaScript hacks, which add more attack vectors and sometimes cannot be implemented properly — such as background media playback, privacy features like WebRTC blocking, and local network blocking.

GeckoView is a single-process engine by design. If you are defending against theoretical issues like memory corruption or Gecko vulnerabilities, that is a much more targeted and advanced threat. In that case, you should not use Gecko, Firefox, or even more hacky WebView wrappers.

Firefox for Android does not even support Multi-Account Containers (MAC). If Mozilla hasn't implemented or stabilized this isolation logic for their own mobile browser, how is Peel enforcing it? Are you relying on experimental or undocumented GeckoView APIs?
Is session isolation really foolproof and native to GeckoView? Why is it not yet implemented in Firefox for Android itself?

Peel uses the contextId feature of GeckoView: link. This is the same infrastructure that powers Firefox desktop containers (userContextId), private browsing (privateBrowsingId), and first-party isolation (firstPartyDomain).
It can be trusted, just as we trust Firefox and other Mozilla products.

How does a single shared GeckoView runtime handle Android's background lifecycle (onPause, onStop) for individual web apps?

The GeckoView runtime is a singleton tied to the application process. Each web app gets its own GeckoSession with an independent lifecycle. When a web app goes into the background, its session is suspended with setActive(false), which pauses JavaScript execution and rendering. When it returns to the foreground, setActive(true) resumes it.
If background media playback is enabled for that app, suspension is skipped so audio can continue.
When the activity is destroyed, the session is closed, but the runtime survives for other apps. If the process is killed, everything stops. On the next launch, sessions are recreated from scratch, while persistent data like cookies and storage remains on disk, keyed by contextId.

I have a few doubts.

If you prefer WebView for some reason:

1. You can stay on version 0.27.1.
2. You can create a fork — following the license, of course.
3. You can use the NativeAlpha app.

[RohitSurwase]

Thanks for the detailed clarifications — the explanations around contextId, the WebView design-scope argument, and session lifecycle management all make sense. Looking forward to v0.30...