Notes on Firefox development
27 June, 2011 § 2 Comments
Today marks the start of my third week at Mozilla. I’d like to mark this occasion with some things that I have learned that are pertinent to developing for Firefox.
-
review?
When I submitted my first patch to Mozilla, I added a reviewer by appending r=reviewer to my patch. While this may say what you mean, it doesn’t do what you mean.
To properly request a review, set
review
to?
in Bugzilla when you are adding an attachment. This will properly email the reviewer so they can become aware of the request. -
make -s -C objdir
Running a clean build of Firefox can take about 25-30 minutes, while an incremental build can still take about 2 minutes. This is clearly not conducive to an iterative-style of coding.
To make builds faster, you only need to rebuild the parts that have changed. To do this, simply run
make -s -C objdir
, whereobjdir
is the parent directory within the object directory of the code that you have changed. It may be necessary to also re-link if native code has changed. -
-moz-appearance: none
This was the first XUL gotcha that I ran into. I bumped in to this as I was working on bug 598169 and trying to make a XUL:textbox styleable.
Many XUL elements use OS-dependent styling, and if you want to apply styles to them then you will have to turn off the default styling.
-moz-apperance: none
does just that. -
hg qpush –move patch
Many of the developers at Mozilla use the
mq
extension for Mercurial.mq
is a tool that allows you to keep all of your changesets in separate queues. This makes it easier to work on different patches in parallel.Most work can be done with three of the
mq
commands:hg qnew
,hg qpush
, andhg qpop
.A normal
hg qpush patch
will push the current patch as well as all preceding patches on the tip, whereashg qpush --move patch
allows a user to push just the single patch on the tip. -
pymake
If you’re working on Windows, Firefox can take a while to build when using the standard
make -f client.mk
. Fortunately, there exists a tool that makes your builds run a lot faster by taking advantage of the multiple cores on your system.Running
python -O "..\build\pymake\make.py" -s -j12
will build Firefox with 12 concurrent compilations. I chose 12 because it is 1.5x the number of threads on my system. :dolske ran some benchmarks to find the optimal-j
setting and advised me on the 1.5x multiplier.You can learn more about pymake on the Mozilla development website.