GeckoView for Android | Hacker News Reader

GeckoView for Android

mozilla.github.io

406 pointsselvan127 comments

GeckoView is awesome. We switched to using it with TelemetryTV (a next gen digital signage platform) and it's made our Android app a lot more compatible.

The core of our player application is a Progressive Web Application that runs everywhere and just needs a native container like Electron or a Webview to run. Our customers run on whatever hardware they want(Windows, Mac, ChromeOS, etc)and Android is a really compelling platform since there's a ton of inexpensive AndroidTV devices out there but quality is all over the place.

If you depended on the system provided Webview on AndroidTV you may get anything from version 50 to 80 of Chrome due to fragmentation of the platform and poor update habits of some manufacturers. Our app uses features like CSS grid and doesn't run on a large fraction of Webviews out there in the wild.

The system Webview also doesn't provide much control at all for customizing the browser engine. GeckoView lets you do pretty much anything allow us to support important features we provide with our Electron clients.

You also don't need to worry about a browser update causing trouble as you control when you update the browser engine.

It's a shame that iOS doesn't have something similar because it's a really horrible platform due to Apples Webview for use cases like ours.

I really need to do the same for my ionic app.

would you please write a blog post detailing how did you achieve this?

Or better provide a github repo as an example

thanks

Sorry, dont really know much about Ionic. The GeckoView site should have all you need to implement it instead of a Webview, it's pretty straight-forward.

>You also don't need to worry about a browser update causing trouble as you control when you update the browser engine.

This concerns me. Under the current google model, as long as you have a play store compatible device, you get chrome webview updates through the play store, even if the device fw is eol.

If an app developer doesn't update their app, then you can have potentially vulnerable version of geckoview lying around. I hope a decoupling/webview-style update mechanism is eventually implemented, although I don't know how feasible that is (i'm an amateur android dev)

That said, I really do like the project. And, I use firefox as my personal browser, both on principle and because it's quality software.

On many real world AndroidTV devices (I've tested a couple dozen) you definitely do NOT get Chrome updated properly even though it's supposed to.

Android is the Wild West, with all the good and bad that follows. Manufacturers are often not implementing things properly. Problem is that these devices are all over Amazon and people buy them and expect them to work. We try to steer people to good quality devices such as the Nvidia Shield but you can only do so much.

Keep in mind that GeckoView may not be used to build a browser. Rather it's often an engine used to drive an application built with web technologies. So a developers requirements for updates are different than an interactive browser of arbitrary web content.

The story is the same on the desktop with Electron. When you deploy an electron app the browser underneath it is locked in conjunction with the version of Electron.

It's still up to the app developer to be responsible and follow issues and update as required. But that's a lot less often than when you have a browser of arbitrary web content.

>On many real world AndroidTV devices

i gathered from your comment about large amts of devices still on 50 D:

I know it won't be used for external web content, but all it takes is an escape or malicious frame/xss, and boom, mass RCE.

I don't like electron for the same reason.

I'm not saying that it's a wasteland out there, it's just one element that concerns me, is all.

Still, at least this provides another option. Lesser of two evils and all that. Maybe if android was less of a mess this would be a less desirable option, but frankly I’m pretty happy there’s an alternate option regardless of whether it’s better or worse

> Keep in mind that GeckoView may not be used to build a browser. Rather it's often an engine used to drive an application built with web technologies. So a developers requirements for updates are different than an interactive browser of arbitrary web content.

It most certainly can :) the new Firefox for Android uses GeckoView.

Yep, of course.

To clarify: when I said “may not” I meant in the sense “might not” rather than it isn’t permitted.

> Under the current google model, as long as you have a play store compatible device, you get chrome webview updates through the play store, even if the device fw is eol.

lol I have a shitty tablet at home with Android 7 to tinker with and when I go on the Play Store is says that Google Chrome is not compatible with the device. It has something like Google Chrome 50 preinstalled and can't be updated.

Good luck getting an updated version of WebView.

As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app.

This is completely up to them of course, and it probably let them move firefox forward faster, due to not having to care about APIs. However, it also means that chrome completely took over the entire market with electron and similar things.

I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web.

As you said, this is too little, too late. I'm a Firefox user, but Chrome has pretty much won the browser wars. The only thing preventing it from achieving complete market dominance is the existence of Mobile Safari.

Mostly because it is a lot of work and tends to lead to new and exciting compromises.

This is for example why Chrome decided to fork WebKit.

(I do believe that people messed around with Electron drop-in replacements, but it's probably hard to sell if it doesn't bring anything new to the table.)

It is expensive, but also it is a competitive advantage (of sorts), as we can see with electron. At the end of the day its just a strategic decision Mozilla made to focus on the application itself.

> If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web.

People coding specifically to Chrome when writing Electron apps is way less harmful to the web than people doing the same with web pages. The latter case specifically hurts other browsers, because people who don't use Chrome can't use the site.

Additionally, each Electron app represents a (smallish group of) developers. They're a very small number compared to all the developers writing public-facing websites that (should!) work in all commonly used browsers.

It makes a difference though. The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off. It’s likely they would have chosen something else if that wasn’t the case (or maybe continued with their own web tech).

> The fact that Chromium is Electron’s backend is why MS picked Chromium to base Edge off.

What evidence do you have for this?

AFAIK the main reason why Microsoft picked Chromium is that Web sites are pretty much guaranteed to work well in Chromium without Microsoft having to do any work.

> What evidence do you have for this?

they stated that their experience with CEF (Chromium Embedded Framework) was instrumental in their decision.

VSCode (built on electron) was probably the main PoC for them.

OK. I doubt the absence of CEF would have changed their decision though.

Not strictly evidence but look like MS is working to have a shared base install of Electron on Windows.

https://docs.microsoft.com/en-us/microsoft-edge/hosting/webv...

FWIW that is apparently for "rendering Web content" inside a Windows application, and that's what the examples do; not clear to me that it's exposing Electron.

> It’s likely they would have chosen something else if that wasn’t the case

Brave is run by ex-Mozilla folks and started with Gecko, but switched to Blink very early on. [1] Their reasons didn't include Electron, so Microsoft's may not have either.

[1] Collection of tweets, and a response from someone at Brave: https://www.reddit.com/r/BATProject/comments/9jpqde/brave_br...

(Disclosure: I work for Google, though not on Chrome. Speaking only for myself.)

Electron is nice for a quick and dirty app. Sadly, people think it's ok to use it for making apps that people are going to use.

What I mean by this - I can recognize a non-Elector vs Electron app by the amount of RAM it consumes. Is your simple color picker/text editor/REST caller/mouse config/ToDo app taking 1GB+ of RAM? It's an Electron app.

For the record, I doubt FF based app would face much better.

And the CPU usage spike as you type into a simple textbox. Without even looking at RAM usage. Text input lag and UI slowness gives it away at the first interaction.

At this point, I could almost tolerate the wasted RAM and CPU if interaction latency wasn't that bad.

Well you gotta shuffle those GBs.

It was funny when I realized that mobile-first also means safari-first for the iOS world.

Supporting embedding well is a lot of work, both to create the APIs and then deal with their constraints as the browser evolves. Mozilla has always been under-resourced compared to the competition (IE, then Chrome) and taking people off improving Firefox/Gecko to work on embedding never made the cut. I don't really regret those decisions.

What made it extra unappealing for Mozilla was that we knew the Firefox/Gecko architecture needed lots of work that would destabilize an embedding API. Not much point in supporting an API that assumes single-process while you're moving to multi-process, or that exposes XUL which you know is a dead end, or that isn't compatible with off-main-thread rendering or GPU rendering, etc. Things are much better now that a lot of that debt has been paid off.

There's nothing stopping a 3rd party from making an Gecko version of Firefox. Electron is not run by Google nor the Chromium team. It's run by github (which only recently became Microsoft)

That said, I'm not sure what the point is. I believe (but could be wrong) that Chromium has more features that Gecko doesn't? So if you're choosing one over the other I'm only guessing most people would choose Electron

"Electron for Gecko" was in fact done. See Positron discussion below.

I don't have any direct insight into why the Atom people chose Chromium but I can see a few reasons that are more likely than "features":

-- Chromium was faster. (For Electron apps you don't really care about Web compat, where Firefox was ahead of Chromium for a while, but you do care about performance.)

-- Chromium was already multiprocess and had some other architectural advantages where Gecko was still catching up. So, less upcoming architectural churn.

-- Chromium had Google's resources committed to it. (Google's shine has worn off a bit since then but it's still a powerful effect.)

Yep, and even now, the Fission (site isolation) work is still causing a ton of architectural churn everywhere.

> Mozilla has always been under-resourced compared to the competition (IE, then Chrome) and taking people off improving Firefox/Gecko to work on embedding never made the cut.

Yeah, sure, imitating your competition is the right way to handle that. /s

References:

1. https://www.dedoimedo.com/computers/firefox-addons-future.ht...

2. https://www.dedoimedo.com/computers/firefox-disable-australi...

3. https://www.dedoimedo.com/computers/firefox-29-sucks.html

4. https://www.dedoimedo.com/computers/firefox-suckfest.html

Moving away from the unsustainable XUL extensions model ("no stable API boundary, just feel free to poke the internals of Firefox any way you like") was another piece of architectural churn that had to happen.

Considering the potential performance issues of Electron apps, I am still hopeful that someone can come up with an Electron alternative with the right engine, but I don't know if that engine is Gecko or not.

>> Chrome has pretty much won the browser wars

Probably the same could have been said about IE ~20 years ago.

This is less of a war, more of a never-ending race. Currently (temporarily?) Chrome is ahead.

> I've always wondered why Mozilla doesn't make it easier to embed Gecko everywhere it possibly can. If Electron was built with Gecko, it would go a huge way towards preventing Chrome from becoming the de-facto way of accessing the Web.

On desktop Mozilla did that: https://en.wikipedia.org/wiki/XULRunner

It was quite successful und I never understodd what happend for them to abonded it and let mozilla run down so deep into s* as it is now.

"Quite successful" is perhaps an exaggeration. Most of the projects using XULRunner were directly related to the Mozilla project (forks of Mozilla Navigator and Composer, Thunderbird, Chatzilla, etc). There are very few projects which independently chose to use XULRunner.

https://en.wikipedia.org/wiki/Category:Software_that_uses_XU...

> As the original author of GtkMozEmbed I'd like to say that this is way too little, way to late. Mozilla has historically been very much against anyone trying to use the engine in anything other than the firefox app.

Your comment reminds me of a 15 or 20 year old remark from Feeddemon and Topstyle author (Nick Bradbury) about how he gave up baking firefox preview into his CSS editor.

https://nick.typepad.com/blog/2008/03/can-mozilla-be.html

I loved Topstyle. It was the first editor I invested time into (after Visual Basic for windows 3.11 in the 90's but I was a kid, not a professional or a student).

XUL could have been a tolerable cross platform toolkit. Still not sure how you can blow something like that.

Remember XULRunner that was doing Electron stuff about 6-7 years before the first version came out. Mozilla has so many good ideas and such terrible execution.

XULRunner was working great.

Unfortunately, there were strategic decisions to basically never maintain it :(

The problem is that XUL was a) nonstandard and b) pretty badly designed and implemented. (For example: XUL trees relied on Javascript callbacks being called at paint time in horribly unsafe ways; XUL flexbox never integrated well with CSS block layout.) It was mostly hacked together in a hurry to get Netscape 6 out the door (and we know how that went). It was XML-centric and the Web ended up going in a different direction. All in all, it was clear pretty early on that XUL was going to be a dead end. Most of the good parts of XUL were standardized as CSS features (or in a few cases, HTML features).

Given more resources, Mozilla absolutely could have done a better job of transitioning faster from XUL to standards-friendly equivalents, and popularizing the latter in an Electron-like framework. But there was never a time when Mozilla had excess resources floating around, and other things took priority. (Also see my comment above about how architectural churn made it unattractive to support a stable embedding API.) As was pointed out in other comments, the benefits of regular Web market share tend to outweigh the benefits of embedding popularity.

Maybe they lacked resources and dev mind share ? Javascript of those days wasn't javascript of today ? “Apps” were almost just glorified shortcuts for some.

Now that I think about it Winamp 3 had its own interesting application framework (https://en.wikipedia.org/wiki/Wasabi_(software)).

> tolerable cross platform toolkit

..for the 90s. There was very little about XUL that would survive today other than its layout model

Ignoring that XUL has a single implementation and for the most part a single application suite actually using it (not 100% true but very close), I'm not sure what there was to blow.

OTOH I remember some custom XUL apps of yesteryear, and they were always pretty nice to use. Does Firefox have any XUL left? I know there have been ideas to rip it out for a very long time.

I remember there was a whole Linux distro written in XUL. Can't remember its name for the life of me, but from memory it was vaguely based on RedHat and was targeting kiosks and internet appliances. I remember setting it up for my parents circa 2001 as it looked fool proof and tamper proof.

> XUL has a single implementation

What's the issue with that? GTK, WPF Qt, Flutter ... all have a single major implementation.

> for the most part a single application suite actually using it

That is now, but it could've been a lot different.

I'm not that familiar with XUL (I'm just old enough to experience it being phased out) but it appears like a great idea to me: XML is not exactly bad for a UI, but XAML is Microsoft-specific (and not exactly great) and HTML is made for documents (leading to problems with worries about semantic tags, lack of layout features ...).

I also quite like how well Firefox integrates with all kinds of platforms. But who knows, maybe that's not in XUL, but specific to FF.

> Does Firefox have any XUL left?

Yes, recently there's been a big rewrite of lots of things as web components, but some XUL leftovers are still there.

Clearly you never tried the original Firefox for Android, which was XUL-based. It was unusable.

I remember trying it on my Nexus One, back when that phone was hot shit. Constant full-screen checkerboarding.

Mozilla literally had to rewrite Firefox for Android and eliminate XUL from the Android version before it became a usable product.

Yeah, the Sailfish OS project, which is an operating system for mobile devices. They use Gecko as engine for their default web browser, but are always lagging with engine updates as every time they have to painstakingly rebase all of their embedding patches on top of the new Gecko codebase.

Same thing happens with CEF, QtWebKit (sometimes they just drop some features to update to a new version)

Why do they not use the ESR version?

I think they do, just an old one as ESR AFAIK does not guarantee you stability of the internal APIS needed for embedding between ESR versions.

I think it's at least 45 ESR, as mentioned in release notes ~year ago: https://blog.jolla.com/hossa/

There is an issue tracking the Gecko update on the community discussion/bug reporting tool used for Sailfish OS: https://together.jolla.com/question/133621/update-gecko-in-t...

The source of the Sailfish OS browser lives here: https://github.com/sailfishos/sailfish-browser

(Even though Sailfish OS is sadly not fully open source, the browser is as are other core applications and frameworks.)

Thank you so much for creating GtkMozEmbed. I spent a good part of 2004 working with it. The most fun I had was hacking it to run on Windows. I recall having to inject a callback function into the win32 event loop with assembly. It was like the coolest just out of college project ever for me.

I wonder if they changed the licensing to something you can actually use in a non FOSS product. Way way back (8 years ago?) we were deciding between webkit and gecko for our solution (we needed a web engine for server side GFX rendering) and the licence made it very simple for us to decide - WebKit was MIT, Gecko wasn't.

> we needed a web engine for server side GFX rendering

> the licence made it very simple for us to decide - WebKit was MIT, Gecko wasn't.

...So what? If it runs on your server, it could be just about anything and it wouldn't matter so long as it's not AGPL. Or was the server meant to belong to the customer?

It can be used in proprietary software. You shouldn't, because that's unethical, but the MPL isn't a strong copyleft. And even with strong copylefts, there are only three that I can think of that apply to software that won't end up on user devices.

Wasn't WebKit LGPL (because of the KHTML heritage)? I was under the impression that, for commercial usage, Gecko (with MPL) was more friendly. Either can be made to work, of course.

Yup, I built my little browser on Chromium due to ease of embedding though I would have loved to use FF.

I am investigating a way to use FF on system as is though by providing a custom profile, a user.css to remove everything but the browser window itself (i.e. no tabs, toolbar, etc), capturing it as a native window (e.g. via QWindow::fromWinId and QWidget::createWindowContainer), and communicating with it via marionette or other remote approach. So far it seems to be ok, but it's a bit of a hack.

Have you tried calling it with the same profile multiple times? I've been running into "Firefox is already running" a lot while trying to use it to integrate web apps with the OS ("site specific browser"). Also the WM-Class would never be set according to the command line parameters on the second call, but you probably don't care about that.

Stock Firefox has "-no-remote" option which allows running multiple instances.

But not using the same profile.

For my use case I don't want to call it w/ the same profile multiple times. Once I have the FF process, I'll work with tabs/windows via the remote protocol.

Not sure what language you are using but CEF was good for Chrome under C#. Might be available under C++ too I think.

There was an equivalent Gecko one for Firefox but I could never get it working correctly so deferred to CEF under Visual Studio (think there's a nuget package for it, conveniently).

Also wxWidgets under C++ offers ability to host a local WebView instance or Trident with wxWebView.

This has been in the works since at least 2016. I believe conversations around improving the embedding story were happening before that, too.

Preach. Not only is Gecko a nightmare to embed, Firefox is terrible for headless. It's why something like phantomjs even had to exist.

An embeddable Gecko would've created a wonderful ecosystem around it, produced headless browsers, a much wider range of browser alternatives, and had much more leverage when it comes to standard. They had... 8 years? 5 years? on Chomium and now have one hell of a task to correct that error.

Looking at the code of their new layout engine written in Rust, making it embeddable wasn't even remotely on their minds either. A real pity.

I hope they have a very good story around patches and updates...

Web browsers need patching pretty much every week, and having every app developer needing to re-release their app every time isn't practical. The alternative is a world where my phone can be compromised because an ad rendered in an app using a 3 week old build of gecko had a browser exploit in.

This. Webview is a separate app on Android phones for quite a while now(and also I think chrome mobile is another/newer webview provider), which allows for much faster updates. As much as app developers hate not knowing what version of library is actually running in their apps, it is a net win for the user.

I didn't know about using chrome mobile as webview provider. What are the dis-/advantages of using it? Any experience?

Advantage is that most of the time, you have a fairly new browser engine available for your app, that is not tied to the OS version (especially important on Android). Also doesn't require embedding an 50MB engine (Crosswalk) in your app.

Disadvantage is that as an app developer you're not guaranteed to have any specific version available. Some devices never upgrade the pre-installed version automatically. The user is also able to switch between the Chrome webview and an OS webview on some devices (in developer settings, so it's not common). You can add checks in your app and direct the user to the update links, but requires quite a bit of work to do well.

I'm curious, does the Android WebView also sandbox the browser process separately from the app's data like WKWebView does on iOS? If it does and GeckoView doesn't, that would be quite a big downside.

Android WebView does sandbox the browser and renderer processes since Oreo - https://android-developers.googleblog.com/2017/06/whats-new-...

There is no reason Mozilla could not do that with GeckoView.

But I like the fact that webkit exploit have enabled jailbreaking locked down hardware

Only mostly sarcastic.

Completely irrelevant, you're missing the use case. When you're using embedded web renderer, the point is that you are in control of the content, hence there's 0 security concern. If you don't control the content, then you're not secure with either WebView nor GeckoView.

Mozilla offers many Android components for those building browsers: https://mozac.org/components/

Is there a similar set of components for desktop applications? I.e., as an alternative to electron.

Would there be any point other than being from mozilla?

Feature set is obviously very different.

Gecko is a different rendering engine.

Well, "from Mozilla" is a subset of the larger and more valuable "not Blink"/"not from Google", which is handy if you're worried about an adtech company owning the entire web ecosystem.

There is zserge/webview which is a component that wraps the native webview on a given desktop platform. I haven’t checked it in detail but I’m curious if building an electron-style app framework with this is possible.

https://github.com/zserge/webview

The [Positron Discontinued](https://mykzilla.org/2017/03/08/positron-discontinued/) post describes why Mozilla gave up on building an electron alternative. I think those general comments apply to anyone trying to do the same.

Dang, that sucks. I noticed that he says "its principal feature was that it was Electron-compatible" about Positron.

That's a lofty, and frankly, unnecessary goal.

Maybe Positron could/should be revived, as a thing of its own, an independent Gecko-based app host, with its own API, distinct and separate from Electron.

(I'm guessing the author of Positron was hoping to attract current Electron users by aiming to make a switch as easy and seamless as possible with a compatible API, and while that's valuable, it would be good to just have an incompatible Electron competitor to begin with.)

I fully share your optimism. I've been trying to find a way to do it with no hope, but maybe with the success and segregation that GeckoView brings to Android, we might have more hope in the near future to get something similar for desktop.

I get that it's nice to know exactly which version something is running on, but something i have found myself wanting when writing a small cli-script for downloading youtube videos, is something like Deno allowing me to run somebody's script, or somebody else to run mine, without fear of it damaging my system. But then also with the rendering engine so it could be just "deno run http://host/myscript.ts --allow-net=googlevideo.net,youtube.com --allow-write=." but it allows me to render a more friendly UI. I wish somebody a lot more competent than me would make such a tool from gecko

I'm looking forward to be able to embed GeckoView in my Ionic apps to support older android versions, as a replacement for the now defunct crosswalk project.

The billion dollar (figuratively) question: When will GeckoView for jailbroken iOS come?

Jailbroken iOS is not a billion dollar question, and is probably not a million dollar question either, given how small of a userbase it is.

GeckoView is fairly tightly focused on Java/Kotlin API. While work in the past allowed Gecko to run on iOS [1] this was not maintained.

[1] https://imgur.com/r8Qti and https://bugzilla.mozilla.org/show_bug.cgi?id=1163827

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.)?

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

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.

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.

Is APK size a problem in modern web or mobiles?

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.

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.

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.

Anyone knows if you can bypass/disable CORS restrictions like in Electron ?

Relevant question with answers: https://stackoverflow.com/questions/61375629/allow-cross-ori...

Is this a "shared library" in the sense that when I have two applications using it, it is only installed once?

No, there is no support for third-party shared libraries on Android yet.

Out of curiosity... does anyone know how big this library is in terms of installation size?

I was also interested in this. Not sure how it will look in final APK build, but AAR is 28Mb https://maven.mozilla.org/maven2/?prefix=maven2/org/mozilla/...

Why not servoView?

Probably because Servo isn't anywhere close to ready yet, unfortunately. It's really cool tech, and I'm dying to use it.

I have a gut feeling that by the time servo is ready, Firefox will have died. That, or servo will never be ready.

Servo may not ever be ready by design, as it is a research project and not meant to stand on its own. The way it's useful is that parts of it occasionally get integrated into regular Gecko as they mature.

The plan for Servo is to integrate it in Gecko piece by piece. In this sense GeckoView (which uses Gecko) will use Servo eventually. It already has WebRender and Stylo from Servo (like the rest of Gecko-powered products).

> Like Firefox, GeckoView offers excellent support for modern Web standards.

I guess it depends on one's definition of "excellent", but I'm still waiting on ES2018's regex lookbehind assertions to be implemented.

What about support for CSS list-style-type: '-'? Happy to discover that it is finally supported since Chrome 79, released on the December 10, 2019. Supported on Firefox since version 39, released on July 2, 2015.

And what about Flex-box's safe value for the justify-content property, allowing to justify (center) an element, but still be sure that the left side of the content will not be hidden if the parent container is too small? Right, supported on Firefox since version 63 released on October 23, 2018 and still not supported on Chrome (and to add insult to injury, safe is recognized, it just does nothing, which is worse than really not supporting the feature).

I didn't look for these missing features on purpose, I have been annoyed by them recently or less recently. So as for Chrome's excellent support for modern Web standard, I guess it depends on one's definition of "excellent".

Or more accurately, you can find lacking support for some features of the Web standard in any browser engine. :-)

I do agree with you, but also I don't think that when judging whether Firefox's support of web standards is "excellent" it matters one bit what other browsers are doing. Like excellence isn't a relative measure here.

Oh, well, it literally depends on what you pick as a definition for "excellent" in a way I hadn't considered then :-)

Food for thought however: what is implemented elsewhere may be an indicator of was level of excellence is achievable.

Yeah, that's why I prefaced my comment with: 'I guess it depends on one's definition of "excellent"'.

What others can do is an indication of what is achievable only if what they do is optimal, like let's say for example that a monkey learns 10 words in a planet full of comparable monkeys and things less capable than that, does that environment make the monkey excellent in general as far as learning words goes? I don't think so. I would argue excellence in this sense is to be measured in the scale of what's possible, not as a comparative measure that changes depending on the environment. In this case in particular I wouldn't consider lacking features spec'ed 2 years ago excellence, your mileage may vary.

Chrome is the baseline here, so you have it backwards.

Looks like they'll be enabled in Nightly for testing in the 78 cycle: https://bugzilla.mozilla.org/show_bug.cgi?id=1634135

That's awesome, thanks for letting me know about it!

Mozilla is going on the completely opposite direction of what their supporters (and previous contributors) want them to go.

Yes, they provide mobile browsers, plus a browser with "private mode" (focus) and now this. But on every single one of them, you have the same philosophy of Google Chrome (tm) adopted, of treating the user as a dumb gullible person that should not have access to important settings.

Why would they waste so much effort, and clone all the things people should avoid from Google Chrome?!

For example, any new tech introduced that can be used for browser fingerprinting and user tracking (e.g. canvas, webgl, webrtc, etc) is enabled to every single site by default, just like chrome.

Some you can install extensions (you can't on this and on mozilla focus), some you can fiddle with user-UNfriendly settings in about:config (desktop and full featured android, not focus or this) where you have to guess setting names and cryptic values (what does 2 means in a setting named somethingEnabled?!)

Only on mozilla desktop you can standardize sane settings by importing a user.js file from the dozen of crowdsourced efforts (i recommend the most complete one from https://github.com/pyllyukko/user.js/ ). think about this, there's more then a dozen community led effort to provide sane defaults, not hardcore user optimized settings, sane defaults, for a project that should be open source and the users could have been able to send in patches to have sane defaults in the first place! now, why would those sane defaults everyone want would be denied in the main branch? because mozilla do not represent the users for a long time!

Mozilla is now a corporation that looks for Advertisement companies grants.

> For example, any new tech introduced that can be used for browser fingerprinting and user tracking (e.g. canvas, webgl, webrtc, etc) is enabled to every single site by default, just like chrome.

GeckoView exposes a wide range of privacy (including anti-tracking and anti-fingerprinting) features in a (hopefully) comprehensive API, see https://mozilla.github.io/geckoview/javadoc/mozilla-central/..., and continues expanding its privacy settings.

> Some you can install extensions (you can't on this and on mozilla focus)...

GeckoView also exposes a WebExtension API, see https://mozilla.github.io/geckoview/javadoc/mozilla-central/..., and continues to expand extension support.

> ...some you can fiddle with user-UNfriendly settings in about:config...

You seem to have answered one of your own questions here.

I also have the impression that you might have not commented on the GeckoView library, but on some range of Mozilla products (you named Focus).

> GeckoView exposes a wide range of privacy

that's is a fallacy and you know it!

There are ZERO settings exposed to the end user.

Those settings are exposed to the App embedding geckoviewer. In other words, the privacy settings are in the hands of the actor who benefit from Advertising by tracking the user!

> GeckoView also exposes a WebExtension API

again to the app.

> There are ZERO settings exposed to the end user.

This thread is discussing GeckoView, which exposes extensive privacy settings.

There is a (hopefully growing) amount of apps based on GeckoView, which will make use and/or expose different variations of GeckoView settings to the user, depending on the purpose and target audience of the app.

You might disagree, but, for example, I consider the level of detail in privacy settings provided by Fenix (Nightly) to be a good balance between user control and comprehensibility.

> > GeckoView also exposes a WebExtension API > again to the app.

Again, taking Fenix (Nightly) as an example, the GeckoView WebExtension API is used to provide a growing selection of add-ons, many of which are aimed at the privacy-conscious user, including uBlock Origin, HTTPS Everywhere, NoScript and Privacy Badger.

> For example, any new tech introduced that can be used for browser fingerprinting and user tracking (e.g. canvas, webgl, webrtc, etc) is enabled to every single site by default, just like chrome.

Who would use Firefox if all those things who are disabled? Probably about as many people who still use Slackware. At which point, what exactly would be the point? The web is at least safer place to be with Firefox in its current state than with Chrome and Edge having 99% dominance.

Maybe people who use extensions that disable all that and let them enable those per-site they trust?

If it were truly open source, we would, gasp, have the best of both worlds by making the UI sane and what the end user wants. Not what a few in the inner circle thinks possible in their limited life experience.

Mozilla killed more projects trying to fix firefox than i care to count. icecat i think was the last one. fenned-by-fdroid was killed and resurrected a couple times, last people i know that contributed left when user.js was disabled after a PR from a google engineer was merged "to make fennec better follow android security team recommendations" or something on those lines.

> For example, any new tech introduced that can be used for browser fingerprinting and user tracking (e.g. canvas, webgl, webrtc, etc) is enabled to every single site by default, just like chrome

They even implemented bad web standards which its absence would not break websites, such as hyperlink auditing and reporting API.

Reply on news.ycombinator.com