Bad news for Mozilla embedders

Thursday, March 31, 2011 20:46 - GNOME

The Heise Online just published an article, Mozilla kills embedding support for Gecko layout engine, without making any fuss it starts with "Mozilla has officially ended support for embedding the Gecko layout engine in applications other than Mozilla core applications", then it links to Benjamin Smedberg post on but it doesn't offer much details, or reasons (other than "our product is firefox, we have to focus ressources there.").

This article ends with an open question, about applications that are currently using Gecko, but it erroneously cites Devhelp. Devhelp has been ported to Webkit a long time ago (I had a post title "Devhelp with Webkit back in 2007).

No worries for Devhelp then; but while it talks about Gecko only this decision may be of concern to us, if it was extended to Mozilla Javascript engine (SpiderMonkey); a few months ago Colin Walters was actually quite positive ("Actually we're discussing this upstream again very productively; there's renewed interest in supporting embedders, and I'm in the process of getting some patches in to help here.") but who knows... Mozilla certainly keeps on ignoring some of our needs, I can't count the number of times jhbuild had to be updated because a xulrunner tarball was removed from their mirrors. (last time? two days ago, bug 645971).

Last Modification: Friday, April 1, 2011 3:44

I think the change is about resources, Mozilla code is changing to a multiprocess model, Firefox for Android already has some of that, and it is not wise to waste resources trying to fix the current single process embedding if that will be scrapped in subsequent releases. I am sure embedding will be easier later and as the porst says, they are open to think about future embedding APIs

Comment by Robert on March 31, 2011 21:02

Actually, nothing changed, except it's now official. So instead of not being supported and embedders not knowing, now embedders know. It also doesn't mean embedding can't be supported, it just means someone has to actually come up and support it. And that's more likely to happen if it is made official that there's no official support. (Who will step up to support something that is believed to be supported?) Though it's not very much likely. I'd strongly recommend people developing applications embedding Gecko to actually step up to develop a NEW embedding layer and maintain it afterwards.

About the xulrunner tarball disappearing, that's doomed to happen, as usually only contains the lastest versions in a given branch. You want if you want to point to older releases.

Comment by glandium on March 31, 2011 21:08

Colin Walters != Colin Watson

Comment by Bastien on March 31, 2011 23:48

@Bastien: Wow, I am left to wonder how long I'll continue to invert the Colins.

@Glandium: Oh, I probably didn't even check but I thought was identical to, just like and I'll switch URLs then, thanks for the info.

Comment by Frédéric Péters on April 1, 2011 3:47

There was a SpiderMonkey release just last night, based on the code that shipped in Firefox 4. SpiderMonkey isn't dropping embeddability any time soon.

Comment by Jeff Walden on April 1, 2011 18:02

Thanks Jeff, this is definitely an important step even if it's not perfect yet; for example the sources layout is not standard, extracting a js185-1.0.0.tar.gz tarball into a js-1.8.5 directory, with the actual sources being in a js/src/ subdirectory, where the configure script lies. I have now been reading bug 628723 and I hope the build system will continue to improve, to match usual standards (I'd favour a spidermonkey tarball, extracting to spidermonkey-x.y.z, building a libspidermonkey, etc.) (and of course some attention to embedders when changing API, not just firefox).

But again, thanks Jeff.

Comment by Frédéric Péters on April 1, 2011 20:49

Comments on this entry have been closed.