Among the most frequent requests we receive from FeedDemon customers is to enable using Mozilla/Firefox as the embedded browser, and this is something I would love to offer. Unfortunately, I don't see how this is possible.
Some history is required here.
Several years ago, Adam Lock created an ActiveX control wrapper for the Mozilla rendering engine (AKA: "Gecko"), and TopStyle was one of the first applications to use it. This enabled TopStyle customers to preview their web pages in Internet Explorer side-by-side with Mozilla - a very popular feature, despite its problems.
Unfortunately, the ActiveX project hasn't been updated since 2005, and appears to have been discontinued entirely. Although TopStyle customers can still use this ActiveX control, it's woefully outdated. This is a big problem because the ActiveX control doesn't embed the version of Mozilla/Firefox that's installed on the customer's computer - instead, it relies on the version of the Mozilla engine that's included with the control. This makes it practically useless, since customers want to know what their web pages look like in the most recent version of Firefox, not one from 2005.
Fast forward a couple of years, when the Mozilla team introduced a new way to embed the Mozilla engine. It's great that this is available, but it's far more complex than the easily-embedded ActiveX control (especially for applications that also embed Internet Explorer). And if I'm reading the docs correctly, it suffers from the same problem as that disbanded project: it requires third-party applications to bundle the rendering engine. Meaning, of course, that it won't automatically be up-to-date with the version of the rendering engine the customer already has installed. So every time a new Firefox build is released, customers will want a new version of our software that includes the updated rendering engine. That's not a sustainable path for popular third-party applications like FeedDemon and TopStyle.
Which brings me to my question: am I missing something? Is there actually a way to easily embed Mozilla in a Windows application, and can it be done in a way that uses the version of the rendering engine that's already on the customer's computer?
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.
http://developer.mozilla.org/en/docs/Mozilla_Embedding_FAQ:Embedding_Gecko#How_do_I_keep_up_with_Gecko_interface_changes.3F
Posted by: Andrew Herron | Wednesday, March 12, 2008 at 09:19 AM
geez, this feature will be awesome if it is doable.
Posted by: Syahid A. | Wednesday, March 12, 2008 at 09:28 AM
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.
Posted by: Andrew Herron | Wednesday, March 12, 2008 at 09:29 AM
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.
Posted by: JJT | Wednesday, March 12, 2008 at 11:08 AM
@JJT - You're looking for IETab:
https://addons.mozilla.org/en-US/firefox/addon/1419
Works a treat and does exactly what you're looking for.
Posted by: Jack Brewster | Wednesday, March 12, 2008 at 11:48 AM
There must be a way...the whole Komodo IDE is built on Gecko...
Posted by: tom | Wednesday, March 12, 2008 at 02:07 PM
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.
Posted by: Mike Shaver | Wednesday, March 12, 2008 at 03:27 PM
*cough*webkit*cough* - just sayin'
Posted by: Ross | Wednesday, March 12, 2008 at 06:33 PM
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 :)
Posted by: Andrew Herron | Wednesday, March 12, 2008 at 10:36 PM
Nick,
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.' :-)
Posted by: Rob Fahrni | Thursday, March 13, 2008 at 02:04 AM
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.
Posted by: Ralf | Thursday, March 13, 2008 at 01:54 PM
Seems like it would be an awesome feature...hopefully they figure a way to make it work!!!
Posted by: Justin M | Thursday, March 13, 2008 at 03:30 PM
@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.
Posted by: Nick Bradbury | Friday, March 14, 2008 at 11:25 AM
@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:
http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/
Posted by: Mark Finkle | Friday, March 14, 2008 at 11:12 PM
The one that the Second Life team uses and developed is http://www.ubrowser.com/llmozlib.php
Posted by: Ryan McCue | Wednesday, March 19, 2008 at 03:16 AM
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:
http://wiki.mozilla.org/Mobile#Embedding_for_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.
Thanks!
Posted by: Christopher Blizzard | Friday, March 21, 2008 at 11:04 AM
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.
Posted by: Clive Walden | Monday, June 16, 2008 at 06:20 PM
It won't be long before someone come up with a solution. It's open source anyway, sooner or later, it will appear.
Posted by: Faizi | Thursday, June 19, 2008 at 02:30 AM