Hacker News Reader

Comment by OJFord | Hacker News Reader

Hm I thought that's what it was, a shame. IMO 'WebViewHandler's should be distributed with browsers, and then when you choose a default browser you've also chosen a default 'WebViewHandler'.

View on HN

I'm not 100% sure, but I think that actually is how it works. I have Firefox Preview (which is built on top of GeckoView) installed as my default Android browser, so I believe webviews from other apps are rendered using Firefox's engine instead of Chrome's.

(Disclaimer: I work for Mozilla but not on this)

WebViews can't be rendered by anything but system WebView or Chrome WebView, but apps can use something called a Custom Tab instead, which can be provided by the user's default browser, and which Firefox does.

It's kind of possible to do that, but I don't know the specifics. Like you can select chrome provided webview or system provided webview. However, looks like gecko is explicitly not providing API compatibility, so looks like a no go from start.

Having looked it up at some point, as far as I can remember the list of permitted Webview providers is hardcoded to the official webview package and the various branches of Chrome (Release/Dev/Canary and whatnot). So you can only use an independent Webview if you're also building your own ROM at the same time, and then you still need to reimplement the whole exisiting Webview API, which could be rather fun if parts of it turn out to depend on Blink-peculiarities that cannot be easily replicated in Gecko.

And finally (and this applies to a standalone GeckoView package without direct API compatibility as well), end users being able to update the Webview independently from the apps using that Webview package means that you're suddenly operating under much more severe backwards compatibility constraints.

Reply on news.ycombinator.com