Forem: EJIRO SONIA

How I Contributed to Firefox as an Outreachy Applicant

EJIRO SONIA — Wed, 15 Apr 2026 14:11:52 +0000

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.

Resources

Outreachy: https://www.outreachy.org
Firefox Source Docs: https://firefox-source-docs.mozilla.org/setup/index.html
Searchfox: https://searchfox.org

Understanding Your Home Network: A Complete Guide.

EJIRO SONIA — Fri, 06 Feb 2026 17:37:14 +0000

Part 1: The Brain and Backbone: Routers, Switches, and the Devices Running Your Internet

Every day, you video call family across the country, stream shows, and work from home - all at the same time, thanks to the internet. This internet connection is made up of smaller network connections from our individual homes and offices.

In this three-part series, we will explore network devices, wired and wireless connections, and how they work together to enable communication and information sharing.

What devices allow you to connect to your local network and access the internet?

Every network connection depends on devices that keep it connected both locally and over the internet, to share and receive information. These devices that enable these seamless connections are called network devices.

Network devices are physical tools that enable computers and other devices to communicate. Without them, devices would not be able to send or receive information over a network or access the internet. They work behind the scenes to move data from one place to another, make sure information reaches the correct destination, strengthen network signals so connections stay stable, and protect the network from unauthorised access.

Common network devices and their functions

Each network device has a specific role they play in a network connection. Knowing the different kinds of network devices helps you build a network that works well and stays secure. Below is a list of common network devices that play a key role in keeping networks connected and running smoothly.

Hub

A network hub is a basic device that connects multiple computers or Ethernet cables to form a single network segment. When a hub receives data from one device, it sends it to all connected devices without checking where it's actually supposed to go. Because of this, hubs can easily cause network congestion and slow performance, especially when many devices are communicating simultaneously.

Hubs do not filter or manage data traffic, so they lack the intelligence of modern networking devices. Some hubs are passive, simply allowing data to pass through, while active hubs strengthen or regenerate signals before sending them out, acting like repeaters for longer distances. With proper configuration, hubs can handle both digital and analog signals. Because of their limitations and inefficiencies, hubs are rarely used today and have largely been replaced by network switches, which handle data more efficiently and securely.

Modem

A modem (modulator–demodulator) is a device that allows computers to send and receive data over communication lines such as telephone lines or cable systems. It works by converting digital data from a computer into analog signals for transmission, then converting incoming analog signals back into digital data that the computer can understand.

Modems are commonly used to provide internet access for customers of an Internet Service Provider (ISP) and often serve as the connection point between a home or office network and the wider internet. They can come in different forms, including external devices connected via USB or built-in hardware.

Switch

A network switch is a multi-port device that connects multiple devices within a network and sends data only to the intended destination. Unlike a hub, which broadcasts data to every device, a switch uses MAC (physical) addresses to determine exactly where each data packet should go. This makes it faster, more efficient, and more reliable.

Switches support full-duplex communication, allowing devices to send and receive data simultaneously, reducing network congestion and improving performance. They can also help improve network security by controlling access to different parts of the network. More advanced multilayer switches can operate at higher network layers and perform routing, allowing them to act as both switches and routers.

Router

A router is a network device that directs data traffic between networks. It connects two or more networks or subnets and decides the best path for data packets to reach their destination. Routers use IP (logical) addresses and store network information in routing tables to forward data accurately and efficiently.

Routers are intelligent devices that can divide a large internal network into smaller subnetworks, allowing each section to operate independently. They can also be connected to other routers, forming larger and more complex networks such as the Internet. When a router does not know the destination of a packet, it uses information from other connected routers to determine where to send it.
Many routers can filter traffic using access control lists (ACLs) and may function as packet-filtering firewalls, thereby improving network security. Routers support both static routing, which is manually configured, and dynamic routing, in which routers automatically exchange information and select the most efficient path using routing protocols.

Repeater

A repeater is a basic network device that helps data travel longer distances by strengthening and regenerating weak signals. As data travels over a cable or wireless connection, the signal gradually weakens, a process known as attenuation. A repeater solves this problem by restoring the signal so it can continue travelling without loss. They simply receive, amplify, and retransmit signals. While dedicated repeaters are less common today, their functionality is often built into devices like hubs, switches, and routers. They are still sometimes used to extend the range of wireless access points or long network links.

Access point

A wireless access point (WAP) is a network device that allows wireless devices to connect to a wired Ethernet network. It contains a built-in antenna, transmitter, and receiver, and it creates a wireless local area network (WLAN) by acting as a bridge between wireless clients and the wired LAN. Making it possible for laptops, phones, and other wireless devices to access the network and the internet.

To connect to a WAP, devices use a network name called an SSID (Service Set Identifier). The WAP may broadcast this name so nearby devices can easily find the network, or it can be hidden for security reasons, requiring users to enter the SSID manually.

Depending on the area's size and layout, multiple WAPs may be needed to provide full wireless coverage and support more users. The range of a WAP depends on factors such as the wireless standard in use, physical obstacles (Walls, furniture, dense materials), and environmental conditions. Some advanced access points include features such as switching, firewall protection, and DHCP services, making them more versatile network devices.

Firewall

A firewall is a network security device that protects a network by creating a barrier between trusted internal networks and untrusted external networks, such as the internet. It controls how data moves in and out of the network by applying security rules that decide which traffic is allowed and which is blocked.
Firewalls often manage traffic between different network zones, such as the LAN (internal network), WAN (external network), and DMZ (a semi-trusted area for public-facing services). They can also be placed inside an organisation’s network to separate sensitive departments from the rest of the network.
Firewalls can be hardware-based, software-based, or a combination of both. They filter traffic using predefined policies, either allowing most traffic and blocking specific threats (blocklists) or blocking everything except approved traffic (allowlists).
It’s important to note that in most home networks, firewalls are not separate devices. Instead, the router typically includes a basic firewall that blocks incoming internet traffic while allowing devices to connect to the internet.

Conclusion

In conclusion, network devices are what make it possible for our devices to connect, share information, and access the internet safely and smoothly. From simple devices like hubs to routers, switches, Wi-Fi access points, and firewalls, each one helps keep a network running properly. Understanding these basics makes it easier to see how your home or office network works.
In Part Two, we’ll look at network connections, both wired and wireless, and explain how they work with these devices. We’ll also cover how to choose the right connection, how speed affects performance, and how data travels across networks.

Reference

Network devices - geeksforgeeks
Network devices: Common types and their functions
Common types of network devices and their functions | Netwrix
How Wi-Fi works | howstuffsworks
Cisco networking course