Create a gist now

Instantly share code, notes, and snippets.

@ednapiranha /
Last active Aug 29, 2015

Firefox development installation (devtools) for OSX

Setting up hg and git clone

git clone
cd gecko-dev
git checkout fx-team
./mach bootstrap
cd ..
hg clone

** [Ignore this note if you are working on your first patches] Note that the hg repo is for you to push to the try server when seeing if the changes break any tests. Not really relevant yet if you are just starting out on patches, but it will become helpful when you start doing more and can run your own tests against the server. You will mainly focus on the git geck-dev repo for most work.

Install git-tools

git clone

In your .git/config for gecko-dev, add this line:

hgp = "show --binary --format=\"# HG changeset patch%n# User %an <%ae>%n%B\" -U8"

Make sure the scripts are executable by your shell by adding this directory to your PATH in your .bash_profile. You can mainly use this for two things - creating the patch and running tests against try:

Creating an hg patch from git

Once you've made changes in gecko-dev and rebased it locally to a single commit in the format of:

git commit -m "Bug 12345 - Summary of bug. r=<name of reviewer>" .

You need to make an hg version of the patch to upload as an attachment for review on Bugzilla. From the git-tools scripts, you can run:

git hgp HEAD > Bug12345.patch

Which will create the patch.

Building Firefox locally

Create a .mozconfig file with the following and add it to the root of the gecko-dev repo:

# adding .noindex will make sure spotlight
# won't index the objdir (slow).
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj.firefox.noindex

export PATH="`brew --prefix ccache`/libexec:$PATH"

. "$topsrcdir/build/mozconfig.common.override"

Run the following in the dir

./mach build

Wait a while... then run your local copy with the command below (set up a new profile for it so you don't override an existing one):

./mach run -p development

After making any changes (CSS, HTML, XUL) that you want to see, run the following:

./mach build browser

** Note that you need to run ./mach build when you have rebased against upstream and have received a lot of updates. If you are just making changes within a tool but haven't rebased upstream, just run ./mach build browser

Running tests

Running tests for the entire suite (not recommended - usually you run it for a particular devtool like browser/devtools/webide):

Entire suite

./mach test browser/devtools

Particular devtool

./mach test browser/devtools/webide

Particular patch

./mach test browser/devtools/path/to/the/test_you_want_to_run.js

Running tests against try [ignore this if you are working on your first patches]

Assuming you made changes to tests for this patch, you will need to run it against the try server (there is a process of getting access to pushing to these servers which you can ping about for help).

Assuming your gecko-dev and fx-team are in the same directory and are siblings, you can go into your gecko-dev dir and run:

git push-to-try ../fx-team -b do -p linux,linux64,macosx64,win32 -u xpcshell,mochitests -t none

There are different configurations you can run (the above is just an example for inspector, rule view, etc) - but you can generate the correct flags for your requirements here


I had to move a file and the rename wasn't reflected in the patch. It turns out that you need to include the --find-renames flag in the alias. So:

        hgp = "show --binary --find-renames --format=\"# HG changeset patch%n# User %an <%ae>%n%B\" -U8"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment