My First Contributions to Firefox: Lessons from Fixing Real UI Bugs

Contributing to a large open-source project always feels intimidating at first. For me, that project was Firefox specifically working within the Mozilla codebase during my Outreachy journey.

This post is a reflection on my experience fixing real UI bugs, navigating the contribution workflow, and learning how to think like a production-level frontend engineer.

Getting started

At the beginning, the Firefox codebase felt overwhelming. There were unfamiliar tools, workflows, and conventions from Bugzilla for tracking issues to Phabricator for code reviews.

I started by picking up beginner-friendly bugs related to the tab system things like layout issues, spacing inconsistencies, and alignment bugs.

These seemed small at first, but they turned out to be great entry points into understanding how Firefox’s UI is structured.

The bug: a simple spacing issue (that was not so simple)

One of the bugs I worked on involved spacing between two UI elements:

The tab note icon
The close button

The requirement was straightforward:

There should be exactly 4px spacing between these elements.

But once I started implementing the fix, I realized the problem was not just about adding margin.

What made it challenging

The UI behaved differently depending on context:

In horizontal tabs, both icons are visible.
In vertical tabs, the close button only appears on hover.
The tab note icon must not “jump” when the close button appears.

My first approach was to prevent layout shifts by keeping the close button in the layout using visibility: hidden.

It worked… but introduced a new problem.

The regression I introduced

A reviewer pointed out that my fix caused a regression:

Tabs without notes lost space for their titles.
The hidden close button was still occupying space.
This made the UI feel cramped.

This was a key moment for me.

I realized:

Fixing one visual issue can silently break another part of the UI.

Iterating based on feedback

Instead of reserving space using visibility: hidden, I learned a better approach:

Keep display: none for the close button (so it does not take space)
Adjust the margin of the tab note icon dynamically
“Simulate” the presence of the close button when it is hidden

This ensured:

Correct spacing (4px)
No layout shift
No loss of space for tab titles

Learning the workflow

Beyond the code, I learned how real-world collaboration works:

Version control

Using git commit --amend to update existing patches
Avoiding stacked commits for a single fix

Code review (Phabricator)

Submitting patches with moz-phab
Responding to “Needs Revision” feedback
Updating the same revision instead of creating new ones

Debugging UI behavior

Testing hover states
Understanding flexbox layout behavior
Thinking in terms of all user scenarios, not just one

Key lessons

Here are the biggest takeaways from this experience:

Small UI bugs can have complex underlying behavior
Always test across different states (hover, active, hidden elements)
Avoid “quick fixes” that introduce hidden side effects
Code reviews are not criticism they are collaboration
Clean commit history matters in large projects

Growth from the experience

This experience changed how I approach frontend development.

I now think more about:

Layout stability
Edge cases
User experience consistency

And most importantly:

I am more confident contributing to large, production-level codebases.

What is next

I am continuing to explore more complex issues in Firefox and improve my understanding of large-scale systems.

If you are thinking about contributing to open source especially Mozilla my advice is simple:

Start small, stay consistent, and do not be afraid to ask questions.

Closing

What started as a “4px spacing bug” turned into a deep learning experience about UI behavior, collaboration, and engineering discipline.

That is what makes open source worth it.

Thanks for reading.