Posts tagged: firefox

Problems building Firefox

By , July 20, 2010 8:35 am

I’ve been building Firefox on Windows recently. Without problems. But then I wanted a build with symbols and that is when the problems started. It is meant to be simple, and it is, so long as you don’t do a

make -f clean

If you do that, then a subsequent build will fail when it comes to updater.exe.manifest.


Assuming you have downloaded and installed Mozilla build and have also installed a suitable version of Visual Studio and the latest Microsoft Web SDK, you can start the build environment by running c:\mozilla-build\start_msvc9.bat (change the number for the version of Visual Studio you are using).

Read these instructions first.

Download the appropriate source tree with a mercurial command like this:

hg clone src192

Basic Build

I’m building on drive M: and have downloaded the source into folder src192.

cd M:/src192

Configure the build with:

echo '. $topsrcdir/browser/config/mozconfig' > mozconfig

Build the build with

make -f build

This gives you a firefox release build. Strangely the build is created without debug symbols. I don’t understand this as debug symbols are really useful even with release builds. The symbols don’t have to ship with the executable code, so there is no good reason for not creating them.

Given that you’ve downloaded the source to build yourself the image its fair to assume that you are probably curious about the internal works or that you may be interested in modifying the source and/or writing an extension for it. Either way, you are going to want the symbols so that you can see what is happening in a debugger. Thus I don’t understand the lack of symbols by default.

Creating symbols

You can create symbols in several ways, by adding the following lines to your mozconfig.

echo 'ac_add_options --enable-debug' >> mozconfig
echo 'export MOZ_DEBUG_SYMBOLS=1' >> mozconfig
echo 'ac_add_options --enable-debugger-info-modules=yes' >> mozconfig

Getting a working build

At this point you’ve already done a build and have created executables. Thus it seems the appropriate thing to do is a make -f clean followed by a make -f build. This won’t work. The problem is that the clean deletes the manifest files that are present in the original mercurial source download.

In the end I wiped the whole source tree, downloaded from the source control again, modified mozconfig with the debug symbol options and did a build. That works.

This took me several attempts to understand – I thought that my various attempts at configuring the debug symbol options were breaking something, so I would change the options, clean then build. Each time taking several hours. I had this working in a virtual machine while I worked on other tasks. I probably spent about a day, including the build times before I decided to try again by starting from scratch.


I don’t know if this is true for non-Windows firefox builds, but if you want your builds to succeed don’t do a make -f clean prior to make -f build as it will prevent you from successfully building firefox.

I hope this information helps prevent you from wasting your time with this particular build problem.

XULRunner Support

By , April 3, 2007 5:08 pm

About a month ago we hadn’t heard of XULRunner. Then the folks at Songbird emailed us asking if our JavaScript tools supported XULRunner.

Its easy to miss a new tool or technology what with all the various development directions people are taking. XULRunner is a platform independent way to write applications using the same technology used to create Firefox and Thunderbird. You use the XPCOM, XUL and JavaScript technologies to create your application. With a bit of magic it then runs on your platform of choice. Songbird are using XULRunner to create a platform independent media player. I guess they know their target market, they are founded by the same people that did Winamp and Yahoo! Music Engine.

Given that we already supported JavaScript for Firefox and Flock support for XULRunner seemed like a natural fit. Ideally it would have worked out of the box, just change a few settings on the UI of our tools and off you go. It didn’t turn out that way, although now we’ve made the appropriate changes, its as trivial as selecting xulrunner.exe instead of firefox.exe when you are choosing the JavaScript runtime.

The first problem we had was that xulrunner.exe doesn’t use the js3250.dll DLL directly, it does it via the xul.dll DLL. As a result the UI and the stub couldn’t find the js3250.dll and thus couldn’t determine the version information we use to choose how to interact with js3250.dll. So we needed to support that.

The second issue was that each js3250.dll we’ve encountered has some internal differences that make line numbers inconsistent unless you use a build against the same header files used for that build. Very annoying, but thats how it is. So we need to know if its Firefox 1.0, 1.5, 2.0, Flock 0.7, or xulrunner to choose the appropriate way to interact with the target. If our tools don’t know they assume you are using the latest and greatest and give you the firefox 2.0 treatment. XULRunner needs the 1.5 treatment not the 2.0 treatment so we had to put in a check for that. Also, the version ids on xulrunner.exe shipped with Songbird are "Personal" and not a version number. Excuse me? Whats up with that? Not very useful information. It should read "1.8" or something similar given that XULRunner is currently at Hopefully someone will fix that.

A third issue was a killer. Songbird triggers a hook that causes a fatal crash. Whoops, how did that get past testing? Same way any other bug does I guess 🙁 Thats life, we are not perfect, so chalk that one up to experience.

We also needed a few XULRunner specific tweaks. For example when you are launching a XULRunner application you are looking for .ini files not .html/.js files.

To sum up, all our JavaScript tools now support XULRunner. This should help all of you using XULRunner to create platform neutral apps using Mozilla technology. If you have any specific issues please let support know at the usual address.

Firefox 2.0 support

By , November 8, 2006 5:29 pm

We’ve just released the latest versions of all our JavaScript tools for flow tracing, code coverage, performance profiling and memory profiling. The latest versions support Firefox 2.0 as well as Firefox 1.5 and 1.0 and Flock 0.7.

Another improvement is that the JavaScript tools automatically prevent any installed debuggers from overriding the hooks required to make the JavaScript tool work. This should remove a regular source of confusion for those trying to use our tools when they have a JavaScript debugger installed.

Finally we’ve improved the JavaScript parsing and also the source code colouring.

Time to start talking…

By , November 3, 2006 5:30 pm

We get feedback from customers from time to time. The feedback tells us about how useful our tools are, about any features in the tools that frustrate them or features they would like to see in the software. Occasionally we also get asked what we are working on and where we are going next.

I usually give a broad brush reponse to this question or if I know the person from previous email I may give a more detailed response. We have decided to add a blog to the site so that we can communicate a bit more about what we are doing and also so that we can announce a bit more clearly any cool things we’ve done that make using the tools that bit easier.

For example, wouldn’t it be great if we could detect that Venkman was trying to load and stop it, so that Venkman and our JavaScript tools don’t fight each other? Thats a common request and its been frustrating living with the fact that Venkman and FireBug (and any other JavaScript debugger) will stamp all over the hooks we’ve put in place and effectively disable our JavaScript software tools. No More! Our next release of JavaScript tools will not require you to uninstall or disable Venkman/Firebug etc.

Panorama Theme by Themocracy