Hacker News Reader

Comment by OJFord | Hacker News Reader

Does this mean a user might open a link and get either WebView or GeckoView, according to what the application developer chose, or that the user can choose which all in-app links open in (if *View enabled in that app, etc.)?

View on HN

That's actually meant to be embedded in the app - so the user gets no choice.

There's a concept of Chrome Custom Tabs - https://developer.chrome.com/multidevice/android/customtabs where the app asks the devices browser to show content hosted inside. Even though the name includes "Chrome", other browsers can provide these as well - I know Firefox for Android and Samsung Browser implement the API and handle the rendering if they're set as default.

App developer chooses either this or that.

However, I bet noone would choose gecko because it adds to the APK size.

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'.

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.

Is APK size a problem in modern web or mobiles?

It depends on what markets you are targetting. A lot of phones being made and sold today have pretty small amounts of storage and users are likely to fill that up. When they do, they'll delete apps, often doing sort by size --- you don't want to be near the top of that list.

Not really, but developers care for some reason. Part of it is user sentiment, part of it is developing markets and feature phones, part of it is data costs. List goes on.

If every app using a Webview started using (and including!) GeckoView instead, the additional space wasted by dozens of GeckoView copies would still start adding up rather quickly.

Reply on news.ycombinator.com