Skip to main content

The newbie's workflow on Mozilla Gecko project

· 5 min read

As our recent development focus shifting from Firefox OS to Firefox, we need to contribute to gecko repository directly instead of contributing to Gaia repository on Github. The most of the works are related to Javascript. The main change is the workflow and API difference.  In Gaia we work between Bugzilla and Github; In gecko, we have Bugzilla and mozReview.

Once you have setup the environment, the workflow could also be based on git(or hg), and most things are dealt automatically. Mozilla is a pretty open workplace so that I can share my workflow with the world. Here is a reference to how I did for per patch/weekly/per setup/one-time workflow.

Do it One time

To become a mozilla committer, read

Create Bugzilla API key and ssh key

Do at every Setup

You may check MDN as a start point, with Developer Guide and especially the source code page

I will do the setup flow every time I got a new laptop.

1. Update git

Use the PPA from the maintainers of git on Ubuntu:

$ sudo apt-add-repository ppa:git-core/ppa
$ sudo apt-get update
$ sudo apt-get install git

2. Install git-cinnabar

Gecko itself managed via mercurial, we need install git-cinnabar to help us deal with mercurial codebase via git.Check `

$ sudo apt-get install mercurial
$ git clone

Then set git-cinnabar into system PATH,

$ gedit ~/.bashrc
export PATH=$PATH:absolute_path_to/git-cinnabar
$ . ~/.bashrc

And do git cinnabar download to get the faster helper.

Then follow `Mozilla: A git workflow for Gecko development to checkout gecko via git.

Make sure you follow the Firefox build guide to setup Firefox build environment.

You can install style check related libraries via the following command:

$ ./mach eslint --setup

You may want install mozreview which improves the overall experience of review with Bugzilla

$ ./mach mercurial-setup

Will clone version-control-tools into ~/.mozbuild/version-control-tools. We need update system PATH

$ gedit ~/.bashrc
export PATH=$PATH:absolute_path_to/git-cinnabar:/path/to/.mozbuild/version-control-tools/git/commands
$ . ~/.bashrc
$ git config --global bz.username [email protected]
$ git config --global bz.apikey [your bugzilla key]
$ git config --global mozreview.nickname gasolin
$ git mozreview configure

Then, run bootstrap script to install required build environment,

$ ./mach bootstrap

Then, the most time-saving advice: setup mozconfig for artifact builds if possible. When you only work for front-end related work (non c++), Artifact build will download compiled platform code to save you lots of build time.

Weekly workflow

Previously build takes more time, I usually do the following command only twice a week if necessary. But now we can use artifact build, which is pretty fast and can be done many times a day.

We need update Gecko repository regularly:

$ git remote update

Then merge recent updates into current repo with

$ git rebase central/default

Checkout a new bug and then rebuild the stack,

$ ./mach build

The command will compile the whole gecko.

Per patch workflow

When I work on a new bug, I'll checkout a new branch (on mac)

$ git checkout -b bugxxxxxxx central/branches/default/tip

or (on Ubuntu)

$ git checkout -b bugxxxxxxx mozilla/central

Usually, the bug is focused on a component of gecko, such as browser/components/customizableui. To make .js/.jsm changes work, we don't need to rebuild gecko. But to make some C++ code or new test code works, we need to rebuild this part of source via

$ ./mach build browser/components/customizableui

Once we have some progress for the patch, we can test code via the command:

$ ./mach test browser/components/customizableui/test

You need to make sure you've followed the JS code style and CSS code style Do the eslint test before commit to make sure the patch does not contain some obvious syntax error.

$ ./mach eslint browser/components/customizableui/test

Once the patch is ready, commit it as normal git commit, with a structured syntax: Bug xxxxxxx - description. ;r=?reviewer_bugzilla_alias.

Then, use git mozreview command to push the commit onto Bugzilla for review.

$ git mozreview push

You can use try chooser to select test suites that run automatically on the test server. Treeherder is Mozilla's test server hosted on AWS (Amazon Web Service). Push code there and everyone will have the same base to validate if your code works well on anyone's computer.

The reference try script (credit from :Gijs) for browser/component is

try: -b od -t none -p win32,win64,macosx64,linux,linux64,linux64-asan -u mochitest-bc,mochitest-e10s-bc,marionette,marionette-e10s

You can manipulate the script based on what you need to test.

If you like to file a bug

  • Assign priorities when filing new bugs that you're going to work on in the component.