How to start contributing to firefox
Have you ever thought about contributing to Mozilla firefox but did not know where to start ? It was my case a few months ago and that is why I decided to write this article.
If the idea of contributing to an open-source project and impacting millions of users while working with both Mozilla staff and volunteers distributed all over the world looks interesting to you, you’re at the right place !
This article is here to introduce you to the process of contributing to firefox, I’ll try to make it as simple and fast as possible. The opinions shared in this post are my own, I’m not writing this on behalf of Mozilla.
The purpose of this article is not to replace the Firefox source docs but rather to gather the most important pieces of information so you can get started as fast as possible and get an idea of what you would have to do in less than 15 minutes. At the end of this article, I hope you will find the process of contributing less intimidating and smoother.
Note that this article will be focused on the devtools project as this is the one I’m currently working on but keep in mind that the tips I will give may vary from one project to another. Let’s get started !
To start contributing you only need:
- a computer with an internet connection
- free time (and discipline)
- knowledge of at least of language used on the product you want to work on (Javascript, Rust, Python, C++) See the full list here.
This article will be split into 4 parts:
- Setting up your coding environment 💻
- Finding your first code contribution 🔎
- Making a change to the codebase ⌨️
- Submitting your patch for review 🎉
1. Setting up your coding environment (~2h) 💻
The first thing you will have to do is to create 2 accounts:
- A Bugzilla account (the tool used to find and report bugs)
- A Phabricator account (the tool used for code reviews) and an API token (Settings > Conduit API Tokens)
Feel free to browse Bugzilla (especially this page) and try to look for components you would like to work on (devtools, firefox, ios, thunderbird, etc…)
You can then start pulling the codebase with git or mercurial (💡 Mozilla recommends using mercurial because it has better compatibility with all the workflows.) If you are coming from git and you want to start using mercurial you can check this repository which “converts” git commands to mercurial commands and explains the different concepts.
hg clone https://hg.mozilla.org/mozilla-central/Do not hesistate to check this great medium article which shows you the most important mercurial commands to get started: https://medium.com/@prathikshagprasad/a-beginners-guide-to-mercurial-for-firefox-development-c17094c72c16
This step should take 40 minutes with a good and stable internet connection. Firefox takes a long time to pull because it’s a monorepo (the code for all projects is located in on repository).
Once the code is pulled, if you are on windows, click here to do a special manipulation, otherwise, if you’re on macOS or Linux you can just start installing dependencies (if you’re not planning to use C++ or Rust, choose the default option which is artifact mode):
./mach bootstrapIf you have any problem, please read carefully this page, you should be able to find any problem you may encounter.
The last step is to build firefox nightly, the unstable testing and development version of Firefox, it gets new features and optimizations earlier than the stable release:
./mach buildThe first build is very long but the next builds will be shorter because firefox uses a caching mechanism called “artifact build” which reduces build time to seconds.
If you are using vscode do not hesitate to type the following command which will build the configuration for vscode
./mach ide vscodeCongratulations ! you should now be able to run firefox locally:
./mach run
You can also type hg wip to see the current tree of commits of the repository
2. Finding your first code contribution (~1h) 🔎
You should now have a working local environment, let’s find a bug you can work on to start contributing !
Note that you don’t necessarily need to do a technical contribution, you can also help Mozilla by doing non-technical work, writing documentation on MDN, or contributing to Mozilla websites for example.
To start, you need to choose which part of firefox you want to work on, just go to this website, it will ask you questions and guide you to the best project based on the answers you give
For your first contribution, I advise you to search on codetribute, you will be able to filter good first bugs by language/project/tag
Go to your favorite project and try to pick a bug you’re excited to fix, it will keep you motivated through the whole process and you will be less likely to give up.
The easiest bugs to work on are the one tagged with “good-first-bug”
Mozilla also has mentored bugs, which means that you will have an assigned mentor that will be here to help you through the process, you can find mentored bugs here
Once you have found a bug you want to solve, write a message on it with your Bugzilla account, if the bug is unassigned, a Mozilla employee will assign it to you. Look at this bug I’ve solved as an example.
As soon as you have the approval to start working on the bug (you should see your name in “assignee” at the top of the page) you can go to the next step !
If you want to contribute to devtools, feel free to check https://bugs.firefox-dev.tools which shows you good first bugs and mentored bugs and helps to find bugs in devtools.
As Patrick Brosset says in this blogpost, devtools is great to start contributing because it feels like web development (you will use js, css, html, client-server architecture…), you get to work with the newest technologies, you will learn how browsers work and the community is awesome.
3. Making a change to the codebase ⌨️
This is the most interesting and also the hardest part: how to fix your bug and check that it does not break anything.
Most of the time, when you take a bug with the “good-first-bug” tag, a Mozilla employee will help you to get started, if you have not received any help and you really don’t know where to start, just ask a question on the bugzilla thread, the mentor of the bug will probably answer you.
Whenever you start working on a new bug, make sure to update your local repository with:
hg pull -uOne tool you should be aware of when you want to search something in the codebase is searchfox, it’s an amazing tool when you need to search keywords fast across the whole codebase. It also shows you who wrote each line on the file you are inspecting.
If you are not sure whether or not you are at the right place, try putting some console.log(“✋ code you are looking for”) in strategic places (emojis will help you to see your message)
When fixing your bug, try to write as little code as possible and try to read the whole context around your code (what are the classes doing in the file, where the state is stored, is there already a function doing what I have to do, etc…). If you self-check your code, you will spend less time on the code review part.
If you feel like you are stuck for more than 2 days do not spend too much time and go ask a question on the firefox chat or on bugzilla
You will probably spend way more time reading code than writing code
I often start to code a helper function to do some task on the browser and realize 1 hour later there is already a function doing this in another file. For example, if you are coding a test to add a new CssRule into the devtools panel, just look for keywords like “addrule”, “addnewrule” “add rule” in searchfox or your IDE, and most of the time you will find the helper function you need.
Once you think you are done fixing the bug, do not forget to lint the code:
./mach eslintif you want to fix the linting errors automatically just do:
./mach eslint --fixIf you are using an IDE like vscode, do not hesitate to install an extension like ESLint to automate this process.
Also, make sure to check your coding style and the efficiency of your code. Depending on the project you are working on, needs are different, on firefox devtools efficiency, performance and speed are really important because you don’t want the UI to be slow when trying to inspect your HTML page.
Before jumping to the next part you will have to do a very important thing: test your code did not break anything
./mach mochitest --headlessthe --headless option allows you to run tests with a headless browser. You can also specify a folder or a file if you do not want to run all the tests
./mach mochitest --headless devtoolsYou will most of the time be asked to write some tests for the bug you are fixing. You can refer to this section to have more information. I usually spend as much time writing tests as writing the actual fix.
Here is an example test I wrote which tests if a class is added to an element when needed:
One last tip for this part: take some time to read the official documentation, it will save you hours of debugging.
4. Submitting your patch for review 🎉
Once you have tested and linted your code, you have to get your code reviewed by someone.
Below is the classic workflow to submit a patch:
Your first step here will be to find a reviewer, if you picked a bug with the “good-first-bug” tag, chances are that you will have a mentor and you can just assign the bug to him. Otherwise, you can look here. Just copy his username somewhere, you will need it later.
Now you can commit your code, if you are using mercurial you can do:
hg add devtools/path/to/file.js
hg commit -m "Bug 1736412 - [devtools] Fix rule button when style node is deleted or moved. r=colin.cazabet"You have to follow these commit message restrictions. After committing your code, save the commit (revision) sha somewhere.
It’s now time to install moz-phab, you can follow the instructions here. Then just push your changes with:
moz-phab submit -iYou will see a phabricator link to your revision with the status “Needs review”
Your reviewer will come back to you after some days and you will probably have to make some changes to your revision (Mozilla puts a lot of care in the robustness and quality of the code pushed, do not discourage yourself because your reviewer asks you lots of changes)
Once you have done the changes, you can amend your commit by doing:
hg commit --amendYou can now resubmit your code with moz-phab as you have done previously. Once your code is approved, it will be landed by your reviewer and your patch will be merged into the integration branch (autoland), which will itself be merged into mozilla-central.`
Firefox uses three primary code repositories: mozilla-central, mozilla-beta, and mozilla-release. These repositories are updated within a defined cadence and built into one of the Firefox products which are released through what is commonly referred to as channels: Firefox Nightly, Firefox Beta, and Firefox Release.
Your patch will then be tested by the QA team and you will be able to see which release version of firefox it will appear on. For example, the bug below was released in version 94. You can check this on the firefox release calendar.
If you are a visual learner, you can check this youtube video which shows the steps to create a patch.
Last tips 💡
- If your code takes too long to get reviewed, do not hesitate to message your reviewer on matrix or to get assigned to other bugs in the meantime
- Code reviews can be really long but you will always learn tons of things on coding style, on the language of your choice, tips and tricks and overall you will become a better developer, it’s worth the time investment
- If you work on parts of the code that you use every day on firefox as a regular user, you will be more enthusiastic and motivated about what you’re doing
Do not hesitate to leave a comment under this post if you want to add something to this article or if you have questions.
I may do more articles on this subject if you found this one helpful.
References 📚
https://firefox-source-docs.mozilla.org/setup/index.html
https://firefox-source-docs.mozilla.org/devtools/index.html#
https://firefox-source-docs.mozilla.org/setup/contributing_code.html
https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html#how-to-submit-a-patch
https://github.com/freeCodeCamp/how-to-contribute-to-open-source#mozillas-contributor-ecosystem
https://tangentspaces.com/2020/04/04/vscode-gecko-coding/
https://www.youtube.com/watch?v=t4chihxNNNQ
https://firefox-source-docs.mozilla.org/contributing/pocket-guide-shipping-firefox.html
https://patrickbrosset.medium.com/contribute-to-firefox-devtools-become-a-better-web-developer-8938a7ad2ebe
