Strap yourself in, this is a long post. It should be easy to skim, but the history may be interesting to some. I would like to make the point that, for a web rendering engine, being embeddable is a huge opportunity, how Gecko not being easily embeddable has meant we’ve missed several opportunities over the last few years, and how it would still be advantageous to make Gecko embeddable.
Embedding Gecko means making it easy to use Gecko as a rendering engine in an arbitrary 3rd party application on any supported platform, and maintaining that support. An embeddable Gecko should make very few constraints on the embedding application and should not include unnecessary resources.
- A 3rd party browser with a native UI
- A game’s embedded user manual
- OAuth authentication UI
- A web application
It’s hard to predict what the next technology trend will be, but there’s is a strong likelihood it’ll involve the web, and there’s a possibility it may not come from a company/group/individual with an existing web rendering engine or particular allegiance. It’s important for the health of the web and for Mozilla’s continued existence that there be multiple implementations of web standards, and that there be real competition and a balanced share of users of the various available engines.
Many technologies have emerged over the last decade or so that have incorporated web rendering or web technologies that could have leveraged Gecko;
(2007) iPhone: Instead of using an existing engine, Apple forked KHTML in 2002 and eventually created WebKit. They did investigate Gecko as an alternative, but forking another engine with a cleaner code-base ended up being a more viable route. Several rival companies were also interested in and investing in embeddable Gecko (primarily Nokia and Intel). WebKit would go on to be one of the core pieces of the first iPhone release, which included a better mobile browser than had ever been seen previously.
(2008) Chrome: Google released a WebKit-based browser that would eventually go on to eat a large part of Firefox’s user base. Chrome was initially praised for its speed and light-weightedness, but much of that was down to its multi-process architecture, something made possible by WebKit having a well thought-out embedding capability and API.
(2008) Android: Android used WebKit for its built-in browser and later for its built-in web-view. In recent times, it has switched to Chromium, showing they aren’t adverse to switching the platform to a different/better technology, and that a better embedding story can benefit a platform (Android’s built in web view can now be updated outside of the main OS, and this may well partly be thanks to Chromium’s embedding architecture). Given the quality of Android’s initial WebKit browser and WebView (which was, frankly, awful until later revisions of Android Honeycomb, and arguably remained awful until they switched to Chromium), it’s not much of a leap to think they may have considered Gecko were it easily available.
(2009) WebOS: Nothing came of this in the end, but it perhaps signalled the direction of things to come. WebOS survived and went on to be the core of LG’s Smart TV, one of the very few real competitors in that market. Perhaps if Gecko was readily available at this point, we would have had a large head start on FirefoxOS?
(2009) Samsung Smart TV: Also available in various other guises since 2007, Samsung’s Smart TV is certainly the most popular smart TV platform currently available. It appears Samsung built this from scratch in-house, but it includes many open-source projects. It’s highly likely that they would have considered a Gecko-based browser if it were possible and available.
(2011) PhantomJS: PhantomJS is a headless, scriptable browser, useful for testing site behaviour and performance. It’s used by several large companies, including Twitter, LinkedIn and Netflix. Had Gecko been more easily embeddable, such a product may well have been based on Gecko and the benefits of that would be many sites that use PhantomJS for testing perhaps having better rendering and performance characteristics on Gecko-based browsers. The demand for a Gecko-based alternative is high enough that a similar project, SlimerJS, based on Gecko was developed and released in 2013. Due to Gecko’s embedding deficiencies though, SlimerJS is not truly headless.
(2011) WIMM One: The first truly capable smart-watch, which generated a large buzz when initially released. WIMM was based on a highly-customised version of Android, and ran software that was compatible with Android, iOS and BlackBerryOS. Although it never progressed past the development kit stage, WIMM was bought by Google in 2012. It is highly likely that WIMM’s work forms the base of the Android Wear platform, released in 2014. Had something like WebOS been open, available and based on Gecko, it’s not outside the realm of possibility that this could have been Gecko based.
(2013) Blink: Google decide to fork WebKit to better build for their own uses. Blink/Chromium quickly becomes the favoured rendering engine for embedding. Google were not afraid to introduce possible incompatibility with WebKit, but also realised that embedding is an important feature to maintain.
(2014) Android Wear: Android specialised to run on watch hardware. Smart watches have yet to take off, and possibly never will (though Pebble seem to be doing alright, and every major consumer tech product company has launched one), but this is yet another area where Gecko/Mozilla have no presence. FirefoxOS may have lead us to have an easy presence in this area, but has now been largely discontinued.
(2014) Atom/Electron: Github open-sources and makes available its web-based text editor, which it built on a home-grown platform of Node.JS and Chromium, which it later called Electron. Since then, several large and very successful projects have been built on top of it, including Slack and Visual Studio Code. It’s highly likely that such diverse use of Chromium feeds back into its testing and development, making it a more robust and performant engine, and importantly, more widely used.
(2016) Brave: Former Mozilla co-founder and CTO heads a company that makes a new browser with the selling point of blocking ads and tracking by default, and doing as much as possible to protect user privacy and agency without breaking the web. Said browser is based off of Chromium, and on iOS, is a fork of Mozilla’s own WebKit-based Firefox browser. Brendan says they started based off of Gecko, but switched because it wasn’t capable of doing what they needed (due to an immature embedding API).
Current state of affairs
WebKit is the only viable alternative for an embeddable web rendering engine and is still quite commonly used, but is generally viewed as a less up-to-date and less performant engine vs. Chromium/Blink.
Gecko has limited embedding capability that is not well-documented, not well-maintained and not heavily invested in. I say this with the utmost respect for those who are working on it; this is an observation and a criticism of Mozilla’s priorities as an organisation. We have at various points in history had embedding APIs/capabilities, but we have either dropped them (gtkmozembed) or let them bit-rot (IPCLite). We do currently have an embedding widget for Android that is very limited in capability when compared to the default system WebView.
It’s not too late. It’s incredibly hard to predict where technology is going, year-to-year. It was hard to predict, prior to the iPhone, that Nokia would so spectacularly fall from the top of the market. It was hard to predict when Android was released that it would ever overtake iOS, or even more surprisingly, rival it in quality (hard, but not impossible). It was hard to predict that WebOS would form the basis of a major competing Smart TV several years later. I think the examples of our missed opportunities are also good evidence that opening yourself up to as much opportunity as possible is a good indicator of future success.
If we want to form the basis of the next big thing, it’s not enough to be experimenting in new areas. We need to enable other people to experiment in new areas using our technology. Even the largest of companies have difficulty predicting the future, or taking charge of it. This is why it’s important that we make easily-embeddable Gecko a reality, and I plead with the powers that be that we make this higher priority than it has been in the past.
31 Replies to “The case for an embeddable Gecko”
Problem is, Mozilla doesn’t have a good tracking record as far as embedding goes. Mozilla will always choose moving faster over slowing down to keep backwards compatibility – even if it means breaking third-party apps. This caused major pain for Camino and K-Meleon only to mention two Gecko embedding projects, to the point where they simply couldn’t keep up with Gecko any more. It was also a massive issue with XULRunner, every vendor building their application on top of XULRunner quickly discovered that changes are being pushed without paying any consideration to their needs. Not to mention that the XULRunner project was constantly understaffed because it was desperately needing the same resources that could be used for Firefox. The result was that rather than becoming a usable platform XULRunner stayed a by-product of Firefox development which nobody wanted to rely on. Do you see Mozilla investing into a platform that other applications will use and keeping up that effort even though it draws some resources away from Firefox? I don’t…
I don’t, either. Some kind of “Electronzilla” project, on the other hand, wouldn’t be drawing any resources away from Firefox. It would double as an investment into bringing about the XUL-free future that lots of Gecko folks are interested in speeding along, anyway.
Also Qt and Gtk seem pretty attached to Webkit. In the Gnome 2.x days I remember much work being invested in embedding Gecko, but it was so difficult I think no one regretted the switch to Webkit.
I have noticed the Wine project still sticks with an embedded Gecko for their html rendering. I don’t know how well that is working, but they do upgrade which version they depend on regularly.
No mention of Camino !!!!
Would be nice to have this properly planned and executed for servo.
Yeah, I suspect Gecko is a write-off, as far as embedding is concerned – there’s been plenty of attempts to make it work, none of them successful. In contrast, Servo does seem to be developed with embedding in mind – if nothing else, because it has no real native UI – and I think there’s more chance of seeing that used in this space than Gecko…
Isn’t this what Servo is doing? Is it worth trying to make an embedding API for both Servo and Gecko?
I agree it is important use case, and I would love for Gecko to have a real answer here. It is (unfortunately) so easy to reach for Chromium based solutions, since it has become so easy to do so via CEF, Electron, etc. I bet some of the applications going down this route would choose Gecko if it were easy to do.
I am not sure what the right approach is technically, but I’d like to help if there’s a way to do so.
On a related front, pushing for a strong embedding API in Servo sounds good as well. An issue https://github.com/servo/servo/issues/7379 was filed a while back about this. I would guess it’s easier to add this to Servo while the engine is young, than it is to adapt Gecko with all the complexity over the years.
Anyway, let me know if there’s a way to help!
“Brendan says they started based off of Gecko, but switched because it wasn’t capable of doing what they needed (due to an immature embedding API).”
hmmm… Wasn’t the removal of Gecko embedding support (2011) ultimately a Brendan’s decision?
I’m a former Mozillian and agree a lot with this, but I also understand why embedded Gecko went by the wayside in the first years around Firefox’s 1.0. Given the huge growth in Mozilla Corp employee numbers around 2011-2013, there’s less of an excuse (especially since so many resources *did* get poured into such a ill-conceived undertaking as FirefoxOS), but getting embedding right is still hard.
Merely “settling” instead for putting out an Electron-like project powered by Gecko would go a long way towards hitting lots of these goals, and retargeting Firefox so that it’s just another Electronzilla app would go a long way towards helping Firefox’s goals, too. It especially sucks that potential Firefox contributors are getting turned away because step 1 is “clone mozilla-central and spend a couple hours building it”, and it’s nuts that the Firefox team is okay with accepting those kinds of consequences.
>> step 1 is “clone mozilla-central and spend a couple hours building it”
Aren’t you exaggerating a bit here? My build machine is an i5 (a few years old) with 4GB of RAM and a conventional hard disk running FreeBSD. Even when starting with an empty build directory, “re-syncing, building and packaging” finishes in under half an hour. And this is with tests left enabled.
I guess an i7 with SSD disks, 8GB of RAM and tests disabled would finish in under 15 min on a first run.
On a machine with specs similar to yours (i3 running Linux, 4GB RAM with HDD, no SSD), time for a clean slate build from scratch generally took 1 to 2 hours. This is supported by the every mention of build times I’d ever come across on devmo, which put reasonable estimates for a builds somewhere around there.
I think the last time I ran such a build was Q1 or Q2 2014. The time frame we’re talking about would have extended back from there to 2007 or 2008, albeit on lesser machines. Things may be different now, but I’m not going to test it, especially since times are different and the recommended specs now involve 8GB RAM—it wouldn’t exactly be a fair comparison.
Even ignoring initial build times, the challenge goes beyond that: if a potential contributor wanted to submit a change, then a rebuild that takes any longer than 60 seconds should be seen as a failure as an open source project—and the same goes for any other project, really.
I also wondered about build times when I built gcc which, with tests enabled, takes hours to build even with an mobile i7, 4GB RAM, SSD. It even errored out because not enough swap was available. In a source based distribution this is a major pain, especially in Guix/Nix where gcc builds are regularly done (you can use prebuilt substitutes however). “If it takes hours today it must have taken days in the 90s?”, I thought at first. My guess though is, the code base was much smaller and thus building took just as long as it takes today. With growing resources, code base grows proportionally.
Thanks for raising this topic up with your blog post. I always wanted to speak about this but I lack the technical expertise to understand the full details to write something about it.
I sincerely hope we — one day — achieve full and real embed-ability of Gecko, heck even Microsoft’s Chakra is trying to blend in (https://github.com/nodejs/node-chakracore). Who’s left? Us unfortunately.
As a Mozillian, who’s personal project is based off Electron.js, every time I’m working on my project I kinda wish this was based on Gecko instead.
I would say if you from Mozilla would spend less time to re-create the Chrome experience (Australis for emulating Chromium UI), Servo (for emulating Blink), removing XUL and your advanced add-on technology for Webextensions (for emulating Chrome add-on invironment to attract Chrome users) and instead do more for being an unique company with own creations instead of playing copycat, then you could have done something like that since quite some long time.
But as long as Mozilla tries hard to make Firefox of the future into more Chrome than “Chrome ever could be” you are moving nowhere.
You understand that problem of yours?
From everything I’ve heard, the ABI/API churn of V8 is much worse than that of SpiderMonkey, so I’m not sure that explains why people are more likely to embed it, or that they are.
Node does embed V8, and tracks the churn, so maybe the answer is that it’s easier to use Node than to create your own embedding (whether that be of V8 or SpiderMonkey).
We (the Adblock Plus project) chose to embed V8 over SpiderMonkey, eventually we built libadblockplus on top of it. Yes, updating V8 is also a pain. The main reason for us was the API – we simply didn’t expect contributors to be able to understand what all the JSAPI calls did. While the V8 API also has to be learned, it doesn’t look like it came from the previous century and it is fairly obvious what the code does.
A few missing pieces of info here:
– phantomjs was written by ariya who was working on Qt at the time, and it relies on the fact that Qt’s gui abstraction allowed a headless mode.
– it’s unsurprising qt uses webkit based stuff when the basis of webkit was khtml which was built on qt.
– being available as an embeddable widget was a goal for khtml, since it needed to replace khtmlw which offered this facility. It’s not an accident that it’s easy to embed.
Disclosure: I’m one of the original khtml devs.
I worked on a series of Gecko based projects (mostly open source), using gtkmozembed and XULRunner between 2000 and 2008. AOL / MoFo / MoCo consistently prioritized their browser products above supporting third party users of the platform. This was frustrating, especially since we would get conflicting signals, but ultimately I think it was the right call. The web is a more important platform than the desktop.
These days there are good embeddable browser solutions on most platforms. Electron has the kind of adoption and support that XULRunner always lacked. Mozilla should focus on its strengths (whatever they are) rather than its weaknesses.
I’ll just note that the N900 & N9 default browsers used Gecko as a rendering engine. Same thing is true for the default browser on Sailfish OS (apparently via embedlite). 🙂
Unless I’m totally mistaken, the Nokia N9/N950 default browser is WebKit2 based, not Gecko based: http://ariya.ofilabs.com/2011/08/first-look-at-nokia-n950-web-browser.html
If you get a gecko engine entirely rewritten in Rust then you’ll have a game changer. The servo project is the most promising project Mozilla has ever out forward. The ramifications are huge for a truly parallel and memory safe rendering engine. More resources should be put into this project if Mozilla wants to be saved.
I totally agree. I’ve been wanting to embed Gecko into things several times, but it’s always such a mess that I’ve had to give up. Getting the Gecko engine into more things will open it up to contributions from more outside groups. It will also accelerate web development in that programmers will be willing create new features that are only used in their own embedded Gecko applications. These features will eventually mature and achieve consensus and be adopted into full web browsers. There is no incentive to do that now because the chance of getting a new feature accepted into all the web browsers is very low. Personally, I find many of the recent new features in web engines to be heavily biased towards the interests of Google and Apple or of some idiosyncratic developers instead of the interests of web application developers. After all these years, a web page can make use of several hugely over-designed collections of audio and MIDI APIs, but it still isn’t possible to save a file. Go figure.
Wow it’s already on news!
AFAIK, Chromium itself doens’t really provide a stable embedding API. Apparently Chromium’s Content API also changes quickly, while CEF as a completely separate project builds stable API on top of it for embedders.
This could be the option for Mozilla as well. If it’s possible to build a separate CEF port on top of Firefox, it might requires less modification to the existing gecko embedding API, not forcing gecko to freeze the embedding API and not necessary to put the CEF port into mozilla-central.
I think this is probably the way to go, along with some acknowledgement from platform teams that they be accessible and cooperative with whoever maintains the embedding product when they break/change/remove something that embedding relies on. The alternative route, I think, is that we have an embedding API in the tree and that it gets used in Firefox, but I think this is a much trickier ask and less realistic.
Its not easy to make Gecko embeddable in the way you describe, if it was I’m sure Mozilla would have done it by now.
However you should look into Servo, its lightweight, embeddable, parallel, cleaner code and faster in certain parts (and not tightly coupled to any browser), its completely standalone. Mozilla are pouring more and more resources into this than Gecko.
For the record, I work for Mozilla – and as far as I know, we aren’t spending more resources on Servo than we are Gecko, not by a long shot. Servo is still probably years away, an embeddable Gecko is eminently more feasible in a short time-scale than a useful Servo is. That said, I hope (and I think they are) Servo team are concentrating on this issue too so they don’t end up in the same place down the line.
OLPC’s Sugar also used XULRunner for a few years before switching to WebKit around 2009. I personally enjoyed that lots of the innards could be replaced with Python components by using PyXPCOM, but of course that meant having to read Gecko’s code for anything one wanted to do, and regressions when testing with newer XULRunners.
Maybe we could have an electron alternative with “SpiderMonkey + Servo&WebRender” when those will be ready. That would be quite a game changer, I just hope Mozilla would put more money towards Servo & WebRender rather than FirefoxOS and Marketing.