In the open source world, there’s a saying that “given enough eyeballs, all bugs are shallow.” At Bugzilla, we’ve taken this principle to heart with our belief that “bugs are cheap” — a philosophy that transforms challenges into opportunities for collaborative problem-solving.
In this post, you will learn more about Mayank Bansal, whose journey embodies the true spirit of open source collaboration. For over a decade, Mayank has contributed across multiple aspects of Firefox development, including web performance. With his experience, he’s known for his exceptional skill in identifying the culprit of performance regression, and has even outpaced our automated alerting system! He’s also been recently appointed as the first official Community Performance Sheriff. Read on to uncover his insider tips and best practices for meaningful open source contributions.
Q: You’ve been a part of the Mozilla community since 2012. What initially inspired you to start contributing?
I have always been interested in software performance. I started using Firefox in 2009. Sometime in 2010-2011, Firefox announced it was working on graphics hardware acceleration, which was a novel technique then. That really piqued my interest. A developer who worked on the graphics backend for Firefox wrote a blog about the progress. I tested the Firefox beta builds on some graphic intensive websites and posted my findings on their blog. The developer responded to my comments and then filed a bug on Bugzilla to track it.
That was the moment when I realized that Mozilla is not your average faceless technology company. It had real developers, fixing real issues faced by real users.
I created my Bugzilla ID and commented on the bug the dev had filed. The devs responded there and fixed the bug. I could immediately test and perceive the improvement on the previously problematic webpage.
That was the positive feedback loop that got me hooked – I file performance bugs, the devs fix it (and thank me for filing the bug!)
Q: You’ve contributed across so many components: from JavaScript and Graphics to WebGPU and the DOM. How do you manage to stay on top of such a wide range of areas?
There are a few things I do:
- I go through all the bugs filed in the last 24 hours in the Core component, which gives me a sense of issues reported by other Firefox users, and bugs filed by the Mozilla devs to track work on either a new feature or performance improvement.
- I read through the bug review comments, which gives me an idea if a particular patch is expected to improve performance.
- I go through the try pushes from the developers, which gives me an idea of upcoming patches and changes.
- I have joined some of the chat rooms on Matrix that Mozilla developers use as team chats. These are generally open to the public (for responsible participation).
A good place to start would be to start cc’ing yourself to large meta bugs (which are like placeholders for other bugs). As new bugs get filed, they will get associated with the meta bug, and you will get an email notification. And then you can go through the new bug and follow that too.
Q: How do you approach bug triaging, and what are some of the challenges you face?
From the description of the bug by the reporter, I try to guess the component where it would sit (DOM, Style, Graphics, JS, etc.). Then I see if I can reproduce that bug. If I can, I will immediately perform a bisection using the wonderful mozregression tool. If I cannot reproduce it, I try to put it in the right component and cc a developer who works in that component. All bugs get triaged as part of Mozilla’s regular process. But cc’ing a developer does cut short some of the lag associated with any process.
I have also been testing the fuzzing bugs created by Mozilla’s fuzzing team. Wherever I can reproduce a crash from the fuzzing testcase, I will perform a bisection and inform the developer. Again, all fuzz bugs get auto-bisected and triaged. But doing it manually cuts some of the time lag.
I also regularly test old bugs and close them if the original issue is fixed now. It feels right to close an old bug and declutter Bugzilla.
Challenges I face are when the details in the bug are not sufficient to reproduce, or when the issue is platform/setting specific, or when the testcase is private and the reporter cannot share. I will ask the reporter for extra information that will help the developers, and most of the time the reporters respond back!
Q: You’ve been known to find the culprit of performance regressions faster than the automated alerting system. What strategies do you use to efficiently track down regressions?
I use AWFY to track performance of Firefox on important metrics and benchmarks. This is a real-time dashboard maintained by the Perf-sheriffing team. As soon as a regression lands, the numbers change on the dashboard. The automated alert system needs minimum 12 datapoints before an alert is generated, which may take a few hours. In this interval, I identify the regression visually, zero-in on the potential range of bugs that could have caused the regression, and then based on my understanding identify a bug that caused the regression. I can then confirm my suspicion by triggering a build with only that bug and run the benchmark that regressed.
Note that the “bisect-build-run benchmark-create graph-generate perf alert” process is fully automated. I only need to press the right buttons, which makes my life very easy!
Q: With over a decade of contributions, how do you see Mozilla’s tools and technologies evolving, and what role do you hope to play in that future?
Tooling continues to evolve in Mozilla. For example, when I started, there wasn’t much source-code analysis. Now, multiple linters are run on each commit to the main repository. Mozilla as a company puts users at the forefront – and those users also include its internal development teams! There is a continuous push to improve tooling to make the developers more efficient and spend less time in mundane activities. The tooling around performance/regression monitoring, Crash Reporting, Telemetry, Build, Fuzzing is ever evolving. In the last few years, tooling around the use of machine learning has also increased.
I see my role as complementary to tools – filling gaps where the system cannot easily make a judgement, or connecting seemingly different bugs with little context.
Q: Through your testing, you’ve discovered bugs on the web where Firefox underperforms compared to other browsers. Can you share how you approach this type of testing?
I follow all the graphics related bugs. As soon as something lands in Nightly, I immediately start stress-testing websites. I also go to sites like Codepen.io and test literally hundreds of relevant demos. Check out some of the bugs I filed for WebGPU and Canvas. With graphics, the issues usually are mis-rendering or crashes.
With Javascript, the issues I found tend to be where we are slower than other browsers, or where the javascript engine (SpiderMonkey) has some hidden quadratic behaviour. Crashes in Javascript are mostly from fuzzing testcases.
I also modify existing testcases or Codepen demos to make them intentionally unrealistic for the browser to process and then report issues. Kudos to the Mozilla devs who try to fix as much as they can and are always happy to analyse my testcases.
In general, if anything feels slow, file a bug. If any website looks weird, file a bug. The tenet in Bugzilla is “Bugs are cheap”.
Q: What advice would you give to new contributors who want to dive in?
Start with following bugs, reading Planet Mozilla, using Firefox Nightly, and installing the Firefox Profiler. Profiler is like an X-ray – you immediately get insight into what is slow in Firefox and where exactly. I spend a lot of time profiling webpages, demos, testcases. I profile anything and everything I find.
Q: What keeps you motivated to continue to contribute to Mozilla?
Couple of motivators: The openness and transparency of development, extremely responsive and friendly developers, feeling of contributing to a piece of software that I use day in and out, belief that Mozilla is important to the openness and democratization of the Web, and finally that my bugs get analysed and fixed.
Q: Outside of your work on Mozilla, what do you enjoy doing in your free time?
Outside of Mozilla, I work within the Investment Banking industry as a transformation consultant in areas like risk, regulatory reporting, and capital markets.
In my free time, I like to read, cook, watch Netflix, and go on long drives with my friends and family.
Interested in contributing to performance tools like Mayank? Check out our wiki to learn more.