Firefox Contributors’ Quick Reference¶
Some parts of this process, including cloning and compiling, can take a long time even on modern hardware. If at any point you get stuck, please don’t hesitate to ask at https://chat.mozilla.org in the #introduction channel.
Don’t hesitate to look at the Getting Set Up To Work On The Firefox Codebase for a more detailed tutorial.
Before you start¶
Please register and create your account for
Bugzilla : web-based general-purpose bug tracking system. To register with Phabricator, make sure you enable Two-Factor Authentication (My Profile >> Edit Profile & Preferences >> Two-Factor Authentication) in Bugzilla.
Phabricator: web-based software development collaboration tools, mainly for code review. Please obtain an API Token (Settings >> Conduit API Tokens)
You need 64-bit version of Windows 7 or later.
Download and install Visual Studio Community Edition.
Finally download the MozillaBuild Package. Installation directory should be:
Before moving on to the next steps, make sure to fulfill the Windows prerequisites
All the commands of this tutorial must be run in the shell provided with the MozillaBuild Package (start-shell.bat)
Bootstrap a copy of the Firefox source code¶
You can download the source code and have Firefox automatically download and install the other dependencies it needs. The below command as per your Operating System, will download a lot of data (years of Firefox history!) then guide you through the interactive setup process.
Downloading can take from 40 minutes to two hours (depending on your connection) and the repository should be less than 5GB (~ 20GB after the build).
The default options are recommended. If you’re not planning to write C++ or Rust code, select Artifact Mode and follow the instructions at the end of the bootstrap for creating a mozconfig file.
To Setup Firefox On Windows¶
$ cd c:/ $ mkdir mozilla-source $ cd mozilla-source $ wget https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py $ python3 bootstrap.py
More information for Windows
To build & run¶
Once the System is bootstrapped, run:
$ cd mozilla-unified $ ./mach build
which will check for dependencies and start the build. This will take a while; a few minutes to a few hours depending on your hardware.
The default build is a compiled build with optimizations. Check out the mozconfig file documentation to see other build options. If you don’t plan to change C++ or Rust code, an artifact build will be faster.
To run it:
$ ./mach run
To write a patch¶
Make the changes you need in the codebase. You can look up UI text in Searchfox to find the right file.
# Mercurial $ hg commit # Git $ git commit
The commit message should look like:
Bug xxxx - Short description of your change. r?reviewer Optionally, a longer description of the change.
Make sure you include the bug number and at least one reviewer (or reviewer group) in this format.
To find a reviewer or a review group, the easiest way is to run
hg log <modified-file> (or
git log <modified-file>, if
you’re using git) on the relevant files, and look who usually is
reviewing the actual changes (ie not reformat, renaming of variables, etc).
To visualize your patch in the repository, run:
# Mercurial $ hg wip # Git $ git show
To make sure the change follows the coding style¶
To detect coding style violations, use mach lint:
$ ./mach lint path/to/the/file/or/directory/you/changed # To get the autofix, add --fix: $ ./mach lint path/to/the/file/or/directory/you/changed --fix
To test a change locally¶
To run the tests, use mach test with the path. However, it isn’t always easy to parse the results.
$ ./mach test dom/serviceworkers
To run tests based on GTest (C/C++ based unit tests), run:
$ ./mach gtest 'QuotaManager.*'
To test a change remotely¶
Running all the tests for Firefox takes a very long time and requires multiple operating systems with various configurations. To build Firefox and run its tests on continuous integration servers (CI), multiple options to select tasks are available.
To automatically select the tasks that are most likely to be affected by your changes, run:
$ ./mach try auto
To select tasks manually using a fuzzy search interface, run:
$ ./mach try fuzzy
To rerun the same tasks:
$ ./mach try again
From Treeherder (our continuous integration system), it is also possible to attach new jobs. As every review has a try CI run associated, it makes this work easier. See Adding Try jobs to a Phabricator patch for more information.
This requires level 1 commit access.
You can ask your reviewer to submit the patch for you if you don’t have that level of access.
To submit a patch¶
To submit a patch for review, we use a tool called moz-phab. To install it, run:
$ ./mach install-moz-phab
Once you want to submit your patches (make sure you use the right commit message), run:
It will publish all the currently applied patches to Phabricator and inform the reviewer.
If you wrote several patches on top of each other:
$ moz-phab submit <first_revision>::<last_revision>
To update the working directory¶
If you’re finished with a patch and would like to return to the tip to make a new patch:
$ hg pull central $ hg up central
To update a submitted patch¶
It is rare that a reviewer will accept the first version of patch. Moreover, as the code review bot might suggest some improvements, changes to your patch may be required.
If your patch is not loaded in your working directory, you first need to re-apply it:
$ moz-phab patch D<revision_id>
Make your changes in the working folder and run:
# Or, if you need to pass arguments, e.g., changing the commit message: $ hg commit --amend # Git $ git commit --amend
After amending the patch, you will need to submit it using moz-phab again.
hg commit --amend -m or
git commit --amend -m.
Phabricator tracks revision by editing the commit message when a
revision is created to add a special
--amend -m is used, that line will be lost, leading to
the creation of a new revision when re-submitted, which isn’t
the desired outcome.
If you wrote many changes, you can squash or edit commits with the command:
# Mercurial $ hg histedit # Git $ git rebase -i
The submission step is the same as for the initial patch.
Retrieve new changes from the repository¶
To pull changes from the repository, run:
# Mercurial $ hg pull --rebase # Git $ git pull --rebase
To push a change in the code base¶
Once the change has been accepted and you’ve fixed any remaining issues the reviewer identified, the reviewer should land the patch.
If the patch has not landed on “autoland” (the integration branch) after a few days, feel free to contact the reviewer and/or @Aryx or @Sylvestre on the #introduction channel.
The landing procedure will automatically close the review and the bug.
Contributing to GeckoView¶
Note that the GeckoView setup and contribution processes are different from those of Firefox; GeckoView setup and contribution docs live in geckoview.dev.