How I Contributed to Firefox as an Outreachy Applicant

#firefox #outreachy #opensource #code

Introduction

Contributing to a browser used by hundreds of millions of people sounds intimidating. But the truth is, Firefox has one of the most structured and welcoming onboarding experiences for new contributors I have encountered in open source. This article is the full story of how I made three merged contributions to the Firefox codebase as part of my Outreachy application, what I actually changed in the code, and what the process looked like from the inside.
If you are new to open source, a current or aspiring Outreachy applicant, or just curious about what contributing to a real browser looks like, this is written for you.

What is Outreachy?

Outreachy is a paid, remote internship program that places contributors from underrepresented groups into open-source projects. Applicants do not simply send a CV. They are required to make real contributions to the project during the application period itself, which means by the time you apply, you have already shipped code.
I have been active in the open source space for a while, so Outreachy was already on my radar. When the May 2026 cohort opened, the Firefox project immediately caught my attention. It was tagged with the Outreachy label, the bugs were well-described, there was an active Matrix channel (#sidebar:mozilla.org), and the mentors were clearly responsive. For someone learning browser engineering, it was the right fit.

Setting Up the Development Environment

The first step before making any contribution was building Firefox locally from source. Mozilla has detailed documentation for this, which I followed step by step. The process felt large at first. There are several things to install and configure, and the initial build takes a while to complete. But working through it methodically, it came together.
Once the build succeeded and I could run my local version of Firefox, something shifted. Seeing the browser launch from code I had just compiled made the whole thing feel real. From that point on, every change I made was one I could open and see in a running browser before submitting it for review.
Throughout the contribution process, I used Searchfox, which is a source code indexing tool for Mozilla Firefox, to navigate the Firefox codebase. It is a code search tool built specifically for Firefox that lets you find every reference to a function, file, or symbol across the entire project. Whenever a bug pointed me to a specific function or filename, Searchfox helped me find all the places in the code that needed to be changed.

The Contribution Workflow

Every contribution to Firefox follows the same path:

Find a bug on Bugzilla tagged good-first-bug or outreachy-sidebar-2026
Comment on the bug to claim it
Make your changes locally, build, test, and lint
Submit a patch on Phabricator for review
Address review feedback until the patch is approved
The mentor pushes to autoland, and your code lands in mozilla-central

Phabricator is Mozilla's code review platform. You submit diffs there, tag a reviewer, and the back-and-forth happens in the review thread. It is different from GitHub pull requests but works on the same principle. You generate a diff of your changes using Mozilla's tooling and upload it directly to Phabricator, where it gets assigned to a reviewer. The reviewer leaves inline comments, you address them, update the diff, and the cycle continues until the patch is approved. Once approved, the mentor pushes it to autoland, and it lands in mozilla-central, which is the main Firefox repository.

Contribution 1: Replacing Deprecated Sidebar Icons

The Problem
Firefox's Sidebar underwent a visual refresh, and as part of that update, new SVG icon files were introduced to represent the collapsed sidebar state. However, the old icon files were never removed, and parts of the codebase were still referencing them. The task was to replace all uses of the old icons with the new ones and clean up the leftover entries.
What I Did
I used Searchfox to find every occurrence of the old icon filenames in the codebase. Once I had a complete picture of what needed to change, I updated each reference to point to the new collapsed icon versions, removed the old SVG files entirely, and cleaned up the corresponding entries in the JAR manifest, which maps icon paths for the browser's theme system.
During the patch iteration, I also caught and fixed a duplicate entry in the manifest, a small but useful find from reading the file carefully.
What I Learned
This contribution taught me how Firefox manages its visual assets and how a change that looks simple on the surface, replacing a filename, can touch more files than you expect once you start tracing every reference. It also gave me my first real experience with the JAR manifest and with Firefox's theming system.
View the commit on GitHub

Contribution 2: Renaming SidebarController and SidebarState Methods

The Problem
Two methods in the Sidebar's state management code had names that did not accurately describe what they did. The names implied that calling these functions would reset everything back to a starting state. But the actual behaviour was different: they only update the properties you pass in, leaving everything else untouched. The fix was to rename them to something that honestly described the merge-and-update behaviour.
What I Did
I renamed the two methods to names that accurately reflect their behaviour. Because these methods were called throughout the Firefox codebase, including in test files, session restore, extensions, and other components, every single call site had to be updated. The final patch touched 22 files.
What I Learned
This contribution reinforced something that stays with me: in a large codebase, naming is not cosmetic. A function name is a contract between the code and everyone who reads it. When the name does not match the behaviour, engineers have to hold two things in their heads at once. Fixing that mismatch, even across 22 files, is real engineering work.
View the commit on GitHub

Contribution 3: Writing test for a component

The Problem
When the new sidebar design was introduced, there were no automated tests to verify that the View menu's Sidebar submenu was working correctly. Specifically, there were no tests verifying that the correct items appeared in that menu, or that each item's checked state accurately reflected whether a given panel was open or closed. Those tests needed to be written.
What I Did
I located the existing sidebar test file, reviewed its structure, and added new test cases to cover the missing cases. The tests I wrote verify that the expected menu items are present and that the checked state updates correctly when a sidebar panel is opened and closed.
What I Learned
Writing tests forced me to understand the component deeply. I had to know exactly how the menu was structured in the DOM and how the checked state gets set and unset. Before this, a future change to the sidebar menu could silently break this behavior with nothing to catch it. Now there is a test that will fail immediately if that happens.
View the commit on GitHub

Reflections

Looking back across all three contributions, a few things stand out to me as worth sharing with anyone considering this path.
Reading code is the real work. Most of my time on each contribution was spent reading and understanding the existing codebase rather than writing new code. Before writing a single line, I needed to understand the shape of what was already there.
Naming and clarity are engineering decisions. The method rename had no effect on runtime behavior. But it made the codebase more honest and easier to maintain. That is real engineering value, not housekeeping.
Tests are first-class contributions. Writing tests were not a secondary task. It was a primary engineering contribution that increases the component's long-term reliability for every developer who touches it going forward.
The community is genuinely helpful. Whenever something in a bug description was not immediately clear, asking a question in the bug thread or on Matrix always elicited a useful, timely response.

What is Next

All three contributions have been merged into mozilla-central and will ship in Firefox 151. I plan to keep contributing to the Firefox Sidebar and take on more complex bugs as my understanding of the codebase grows.
If you are thinking about contributing to Firefox or applying for Outreachy, the bugs tagged good-first-bug are genuinely approachable. The main thing you need is the willingness to read a lot of code and ask good questions.