State of Embedding in Gecko

Following up from my last post, I’ve had some time to research and assess the current state of embedding Gecko. This post will serve as a (likely incomplete) assessment of where we are today, and what I think the sensible path forward would be. Please note that these are my personal opinions and not those of Mozilla. Mozilla are gracious enough to employ me, but I don’t yet get to decide on our direction 😉

The TLDR; there are no first-class Gecko embedding solutions as of writing.

EmbedLite (aka IPCLite)

EmbedLite is an interesting solution for embedding Gecko that relies on e10s (Electrolysis, Gecko’s out-of-process feature code-name) and OMTC (Off-Main-Thread Compositing). From what I can tell, the embedding app creates a new platform-specific compositor object that attaches to a window, and with e10s, a separate process is spawned to handle the brunt of the work (rendering the site, running JS, handling events, etc.). The existing widget API is exposed via IPC, which allows you to synthesise events, handle navigation, etc. This builds using the xulrunner application target, which unfortunately no longer exists. This project was last synced with Gecko on April 2nd 2015 (the day before my birthday!).

The most interesting thing about this project is how much code it reuses in the tree, and how little modification is required to support it (almost none – most of the changes are entirely reasonable, even outside of an embedding context). That we haven’t supported this effort seems insane to me, especially as it’s been shipping for a while as the basis for the browser in the (now defunct?) Jolla smartphone.

Building this was a pain, on Fedora 22 I was not able to get the desktop Qt build to compile, even after some effort, but I was able to compile the desktop Gtk build (trivial patches required). Unfortunately, there’s no support code provided for the Gtk version and I don’t think it’s worth the time me implementing that, given that this is essentially a dead project. A huge shame that we missed this opportunity, this would have been a good base for a lightweight, relatively easily maintained embedding solution. The quality of the work done on this seems quite high to me, after a brief examination.

Spidernode

Spidernode is a port of Node.js that uses Gecko’s ‘spidermonkey’ JavaScript engine instead of Chrome’s V8. Not really a Gecko embedding solution, but certainly something worth exploring as a way to enable more people to use Mozilla technology. Being a much smaller project, of much more limited scope, I had no issues building and testing this.

Node.js using spidermonkey ought to provide some interesting advantages over a V8-based Node. Namely, modern language features, asm.js (though I suppose this will soon be supplanted by WebAssembly) and speed. Spidernode is unfortunately unmaintained since early 2012, but I thought it would be interesting to do a simple performance test. Using the (very flawed) technique detailed here, I ran a few quick tests to compare an old copy of Node I had installed (~0.12), current stable Node (4.3.2) and this very old (~0.5) Spidermonkey-based Node. Spidermonkey-based Node was consistently over 3x faster than both old and current (which varied very little in performance). I don’t think you can really draw any conclusions than this, other than that it’s an avenue worth exploring.

Many new projects are prototyped (and indeed, fully developed) in Node.js these days; particularly Internet-Of-Things projects. If there’s the potential for these projects to run faster, unchanged, this seems like a worthy project to me. Even forgetting about the advantages of better language support. It’s sad to me that we’re experimenting with IoT projects here at Mozilla and so many of these experiments don’t promote our technology at all. This may be an irrational response, however.

GeckoView

GeckoView is the only currently maintained embedding solution for Gecko, and is Android-only. GeckoView is an Android project, split out of Firefox for Android and using the same interfaces with Gecko. It provides an embeddable widget that can be used instead of the system-provided WebView. This is not a first-class project from what I can tell, there are many bugs and many missing features, as its use outside of Firefox for Android is not considered a priority. Due to this dependency, however, one would assume that at least GeckoView will see updates for the foreseeable future.

I’d experimented with this in the past, specifically with this project that uses GeckoView with Cordova. I found then that the experience wasn’t great, due to the huge size of the GeckoView library and the numerous bugs, but this was a while ago and YMMV. Some of those bugs were down to GeckoView not using the shared APZC, a bug which has since been fixed, at least for Nightly builds. The situation may be better now than it was then.

The Future

This post is built on the premise that embedding Gecko is a worthwhile pursuit. Others may disagree about this. I’ll point to my previous post to list some of the numerous opportunities we missed, partly because we don’t have an embedding story, but I’m going to conjecture as to what some of our next missed opportunities might be.

IoT is generating a lot of buzz at the moment. I’m dubious that there’s much decent consumer use of IoT, at least that people will get excited about as opposed to property developers, but if I could predict trends, I’d have likely retired rich already. Let’s assume that consumer IoT will take off, beyond internet-connected thermostats (which are actually pretty great) and metered utility boxes (which I would quite like). These devices are mostly bespoke hardware running random bits and bobs, but an emerging trend seems to be Node.js usage. It might be important for Mozilla to provide an easily deployed out-of-the-box solution here. As our market share diminishes, so does our test-bed and contribution base for our (currently rather excellent) JavaScript engine. While we don’t have an issue here at the moment, if we find that a huge influx of diverse, resource-constrained devices starts running V8 and only V8, we may eventually find it hard to compete. It could easily be argued that it isn’t important for our solution to be based on our technology, but I would argue that if we have to start employing a considerable amount of people with no knowledge of our platform, our platform will suffer. By providing a licensed out-of-the-box solution, we could also enforce that any client-side interface remain network-accessible and cross-browser compatible.

A less tenuous example, let’s talk about VR. VR is also looking like it might finally break out into the mid/high-end consumer realm this year, with heavy investment from Facebook (via Oculus), Valve/HTC (SteamVR/Vive), Sony (Playstation VR), Microsoft (HoloLens), Samsung (GearVR) and others. Mozilla are rightly investing in WebVR, but I think the real end-goal for VR is an integrated device with no tether (certainly Microsoft and Samsung seem to agree with me here). So there may well be a new class of device on the horizon, with new kinds of browsers and ways of experiencing and integrating the web. Can we afford to not let people experiment with our technology here? I love Mozilla, but I have serious doubts that the next big thing in VR is going to come from us. That there’s no supported way of embedding Gecko worries me for future classes of device like this.

In-vehicle information/entertainment systems are possibly something that will become more of the norm, now that similar devices have become such commodity. Interestingly, the current big desktop and mobile players have very little presence here, and (mostly awful) bespoke solutions are rife. Again, can we afford to make our technology inaccessible to the people that are experimenting in this area? Is having just a good desktop browser enough? Can we really say that’s going to remain how people access the internet for the next 10 years? Probably, but I wouldn’t want to bet everything on that.

A plan

If we want an embedding solution, I think the best way to go about it is to start from Firefox for Android. Due to the way Android used to require its applications to interface with native code, Firefox for Android is already organised in such a way that it is basically an embedding API (thus GeckoView). From this point, I think we should make some of the interfaces slightly more generic and remove the JNI dependency from the Gecko-side of the code. Firefox for Android would be the main consumer of this API and would guarantee that it’s maintained. We should allow for it to be built on Linux, Mac and Windows and provide the absolute minimum harness necessary to allow for it to be tested. We would make no guarantees about API or ABI. Externally to the Gecko tree, I would suggest that we start, and that the community maintain, a CEF-compatible library, at least at the API level, that would be a Tier-3 project, much like Firefox OS now is. This, to me, seems like the minimal-effort and most useful way of allowing embeddable Gecko.

In addition, I think we should spend some effort in maintaining a fork of Node.js LTS that uses spidermonkey. If we can promise modern language features and better performance, I expect there’s a user-base that would be interested in this. If there isn’t, fair enough, but I don’t think current experiments have had enough backing to ascertain this.

I think that both of these projects are important, so that we can enable people outside of Mozilla to innovate using our technology, and by osmosis, become educated about our mission and hopefully spread our ideals. Other organisations will do their utmost to establish a monopoly in any new emerging market, and I think it’s a shame that we have such a powerful and comprehensive technology platform and we aren’t enabling other people to use it in more diverse situations.

This post is some insightful further reading on roughly the same topic.

14 Replies to “State of Embedding in Gecko”

  1. Thank you for exploring this! I agree that there’s a lot of missed opportunities by not having a good embedding API and with most of your points. I’d really like for us to have a first-tier supported solution.

    I remember the meeting in Whistler (2010?) where we decided to stop maintaining the embedding API. I think it was the right decision *at the time* given the constraints that we were facing. But given that we shed this technical burden for the e10s transition which is now nearly completed and have greatly grown the organization I feel embedding should become a priority once again.

  2. As I just posted elsewhere, I’m a little tired of seeing Mozilla shooting itself in the foot all the time. Your posts make me very hopeful, however, and even if you don’t get to set Mozilla’s direction, I sure hope that Mozilla listens for its own sake.

    I agree with pretty much all of your post. I also think that Mozilla needs to split itself in two: engines and products. In particular, Mozilla Engines needs to create embeddable products that are as developer-friendly as Mozilla products are user-friendly.

    Unfortunately, I rate Mozilla’s prospects over the next 5 years as pretty dour (I’ve never been this pessimistic in the 18 years since it began). But if that’s the case, the community should view it as another phoenix-like opportunity, with the downtime being spent to make sure that Servo and browser.html set good precedents for the engines/products story.

  3. Can you give some insight about this Positron thing?

    https://medium.com/@david_bryant/embed-everything-9aeff6911da0

    Is this a real project with real engineers or is it just something that was done as a reaction to the Tofino embarrassment and will gradually be forgotten when attention moves elsewhere? I guess a more important question is whether a technical writer has been assigned to the project or not because the main issue I have with Mozilla’s projects it that their engineers are not very good at writing documentation, so without a technical writer, the APIs won’t have enough documentation to be usable.

    I don’t want to waste a lot of time digging through that code, trying to understand it if it won’t be maintained for at least 2-3 years.

    1. So I’m not involved with this (and wasn’t aware of it until after it was announced), so I don’t have much more information than anyone else. That said, it appears to be the real deal. I’ll ping Chris Mills and see if he has any idea about the status of documentation writing for this project. I’m cautiously optimistic about this though 🙂

      1. Hi! We are aware of Positron, and I believe we are in the process of starting conversations about the project’s documentation needs. I don’t have anything more concrete than this right now though. I’ll do some digging and see if I can find out anything else.

  4. Jolla and the Jolla Phone is still alive and kicking, unfortunately Jolla had some funding issues late 2015 which meant a lot of developers left the company and so some of the software stack is getting neglected for the time being.

    With the funding issues resolved for the time being a new devices being released, I expect that Jolla will continue to work on EmbedLite, so the project isn’t dead but merely sleeping.

  5. Hi good people.

    I am using Spidermonkey in my projects and I am very tired.
    I have been using SpiderMonkey for about 5 years now, and I can tell you is very frustrating work with this engine. I have a lot of code made with spidermonkey (custom classes and functions) so I never switched to V8 but the last upgrade was … I don’t know how can I say this. They changed everything. I now for a very long time the spidermonkey goal is performance but … come on… We ( the people who embed this) are important too. We are in the same side, but in Mozilla we don’t exist, nobody care about us. It is crazy. If you don’t care the ’embed’ people you will be alone very fast, and the documentation…. what documentation… Please at least when you remove some function write some where what can we do. Write the replacement function or code or work around. Firefox is loosing the browsers fight, please don’t lose the JS engine fight. Think about it!

    1. I heartily agree with your sentiment – thankfully, it looks like embedding will be a higher priority this year, so let’s see how this plays out. The work on spidernode looks like we’ll be implementing the V8 API, so I expect that may end up being the official embedding API going forward (note, I’m not on that team and have no affiliation with that team, this is pure conjecture).

Leave a Reply

Your email address will not be published. Required fields are marked *