« Vote on a New Name for FeedDemon's Next Button | Main | This Post Belongs on Techmeme »

Wednesday, March 12, 2008


Feed You can follow this conversation by subscribing to the comment feed for this post.

Actually judging by this faq entry (and the one below) there are certain integration points they guarantee to be future compatible. Theoretically it would work, but in typical mozilla fashion they don't seem to care if anything linking to them breaks.

The big issue I have with their policy is that they're quite happy to have a compiler dependant API layout; this means that anytime the vtable changes not only do you have to recompile your link to their code but your code will no longer link to anything older than the release where the compiler changed (at least not without an extreme amount of hackery).

Not to mention the fact that you'll have to write a stack of detection code to find a user's installed copy of firefox in the first place, although relying on the registry entries is probably a safe starting point.


geez, this feature will be awesome if it is doable.

heh... scratch all that. I just read up a few entries and realised that even with the interface requirements, you still have to compile your own embedable browser code; they don't distribute it with the normal FireFox download (and I doubt they ever will while they still crow about how much smaller their download is vs IE8).

Allowing use of FireFox as a library just isn't a priority for these guys, and until it is they will continue to play second fiddle to IE in a lot of ways.

That would be nice to have FF as the embedded browser in FD, but I know it was experimental 2-3 years ago, and the development cycle, as Andrew pointed out, just is not in that direction. You would think it is something they are pondering, especially considering their plans for a mobile version of FireFox.

Actually, I have always had one simpler ability in the back of my head: I would love the ability to have FD use Firefox when Firefox is not my default browser--like at work. I love it using the default browser to open external links--something I have to do with lots of newspaper articles--but I need an alternative to address those places where making FF my default browser does not work--mainly those corporate applications we all know and love.

I realize this gets difficult, but I have never dabbled with other ways to do it. I suppose I could do it with some fun Firefox extensions to force certain URLs to open in IE, but I have not had the time to play around with it.

@JJT - You're looking for IETab:

Works a treat and does exactly what you're looking for.

There must be a way...the whole Komodo IDE is built on Gecko...

We would like to make this work more smoothly, and in Firefox 3 you may well have some better options -- the download size hit for the embedding code is pretty trivial, as I understand it, and we've never really been trying to compete with IE on download size. (IE in the dominant case isn't downloaded to start with, so competing with them on that front would be pretty dumb, and there are many fewer ways for people to download-and-forget-about-it even for IE updates given the deliciously tight hooks that MSFT has given it into their operating system. I haven't seen a lot of crowing on that score, mostly just keeping in mind that our download size very much affects our uptake rate by new users through our only real distribution channel.)

There's a dev.embedding newsgroup/list that will likely be able to give you more specific help here, if you have detailed questions or want to trade code snippets. It's mozilla.dev.embedding on Google Groups, or you can get it as a mailing list as [email protected] via https://lists.mozilla.org/listinfo/dev-embedding.

We care a LOT about not breaking things along our major version (stable) lines of updates (2.0.0.x, or the upcoming 3.0.x), and we go to considerable lengths to avoid that; if you've had bad experiences otherwise when linking your software to our libraries, Andrew, I'd be interested to hear about them and to see if we can make them better without handcuffing the development of the platform. (Between major version numbers, we can and will break API compatibility where necessary, though even then we're conservative. I don't know of many platforms that guarantee binary compatibility across major version jumps, since that lack of compatibility is often exactly what's conveyed by such a bump.)

Feel free to mail me ([email protected]) if those channels don't work for you, but it's been some time since I've dabbled in that stuff, and the people on my team and elsewhere in Mozilla who know this stuff best hang out there.

*cough*webkit*cough* - just sayin'

Thanks for checking in Mike!

I don't have any personal use for embedding FireFox anymore, I've moved on from the project that was looking at it a few years ago - but I'm glad to see you're keen to make this work.

The impression I got from the FAQ entries was that the embed code is basically the full browser and had to be recompiled for every FireFox release (thus requiring a new release of the third party application linking to it). Your description sounds like that's not the case which means there's hope for FD :)


After further exploration I'm surprised the Mozilla guys didn't build the Gecko Engine as a standalone .DLL with full backward compatibility. It would appear, as you've already discovered, that you have to build the code directly into your application.

It would be nice if the Mozilla team would build the engine as a .DLL so someone could then wrap it in the IE interfaces, like Adam Lock had done.

It really seems strange to me they didn't, but it is an open source project, and they'll probably say 'Hey, just download the source and build it yourself.' :-)

Well, I just have a TopStyle customer's opinion:

I don't understand what's so good about automatic updating. Contrarily, I think it's *not* better to let a newly installed Firefox update the control.
Best thing for webdevelopers would be to have a couple of controls to choose from so that we can see in our developing application how the page looks in Fx 1.5, Fx 2, later Fx 3, IE6, IE7, Opera and so on.

Seems like it would be an awesome feature...hopefully they figure a way to make it work!!!

@Rob: Yep, that's a big problem for me, since I want to make sure that customers are using the latest version of the rendering engine.

@Ralf: That would be a cool feature for TopStyle (if it were possible), but I'd really want FeedDemon customers to have the most recent version to make sure they have the latest security fixes.

@Rob (& others): The Mozilla ActiveX control *is* still being compiled with the latest gecko engine as part of the XULRunner project. XULRunner, among other things, is the main project for binary embedding of the gecko rendering system. The ActiveX DLLs are delivered as part of the binary distribution of XULRunner.

Unfortunately, not much has been done to add more MSHTML interface wrappers. As long as your application can manage with some basic MSHTML interfaces, you can use the ActiveX control distributed with XULRunner to get the latest gecko rendering support.

XULRunner nightly found here:

The one that the Second Life team uses and developed is http://www.ubrowser.com/llmozlib.php

Hi, Nick! We're also starting down the path of trying to fill out some of our embedding APIs. In the past we've had support for an ActiveX control, a GTK widget and other APIs for doing this but they have never been as supported as well as our browser. We're going to try and make embedding a somewhat more important part of our story. I've started that investingation in the context of mobile:


But it's also applicable to the desktop as well. If you're up for it you can join us and help us out to carve out the next gen APIs and help us understand your use cases.


As an independent software consultant, I am certainly getting interest from clients who want to deliver applications using web technology but also want to control the user experience by embedding the browser engine inside their own application shell.
It also allows us to code to a single browser behavior.
Currently, that forces me down the IE path.

It won't be long before someone come up with a solution. It's open source anyway, sooner or later, it will appear.

The comments to this entry are closed.