DEV Community

Cover image for The Test That Wouldn't Stop Timing Out (And the Mentor Who Found Out Why)
Chukwuka Rosemary
Chukwuka Rosemary

Posted on

The Test That Wouldn't Stop Timing Out (And the Mentor Who Found Out Why)

Summer Bug Smash: Smash Stories 🐛🛹

The Test That Wouldn't Stop Timing Out (And the Mentor Who Found Out Why)

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The Setup

I was contributing to Mozilla Firefox through Outreachy, and my task was to write a browser test for a feature called "Forget About This Site" — verifying that the dialog opens correctly, the Clear Data button works, and the site disappears from the history list afterward.

Straightforward, I thought. Write a test, watch it pass, move on.

It did not go that way.

The Bug

Every time I ran the test, it timed out. Not failed with a clear error — timed out, which is so much worse, because a timeout doesn't tell you what went wrong. It just tells you something never happened in time.

I tried everything I could think of. Removed lines. Added lines. Reordered assertions. Ran it again. And again. Same result, every time: nothing.

I built Firefox from scratch on my laptop with only 14GB of free disk space, running tests at 2AM in Nigeria, staring at a terminal that refused to tell me anything useful.

The Turning Point

Eventually I did the thing that's harder than it sounds when you're new and don't want to look like you can't handle it: I told my mentor, Nikki Sharpley, that I was stuck. Not "stuck but let me try a few more things first" — actually stuck.

She investigated. And it turned out the bug wasn't in my test at all. It was in Firefox's own clearDataForSite.js — a dialog event listener was firing before the window had fully loaded. A race condition baked into the code my test was supposed to be verifying.

She fixed the root cause and pushed it to my patch. Then she wrote: "Other than that, your test looks and works great! Well done!"

What Actually Fixed It

The real fix was ensuring the event listener attached only after the window's load state was confirmed, rather than assuming it was already ready. My test had been correctly written the whole time — it was exposing a genuine timing bug in the code it was testing, which is honestly the best possible outcome for a test to have.

The patch landed in Firefox on April 13, 2026, and was resolved as FIXED in Firefox 151 the next day.


The moment the test finally passed — 148/148, zero failures.

What I Actually Learned

The instinct when something breaks and you don't understand why is to hide it, keep trying quietly, and only ask for help once you've exhausted every idea. I get why — nobody wants to be the person who couldn't figure it out.

But the moment I actually said "I'm stuck" out loud was the moment the bug got found. Not because I was incapable of finding it — race conditions in code you didn't write are genuinely hard to spot alone — but because saying it plainly let someone with more context look in the right place immediately.

A test that times out isn't always a bad test. Sometimes it's a good test doing exactly its job: refusing to pass until the thing it's testing is actually correct.


I'm Rosemary, a self-taught full-stack developer from Nigeria, contributing to Mozilla Firefox through Outreachy. You can find my other work on GitHub.

Top comments (0)