Many of the patches that we write are fixes to things that have broken as a result of a change, often known as regressions. An important aspect of a high quality release is for us to be able to identify and fix as many of these regressions as we can for each release, and this requires collaboration between people who file bugs, those who triage them, people who fix them, and of course the release managers.
As engineers, one of the things we can do when fixing a bug is to double check whether the bug was introduced as a result of a recent code change, and based on that decide whether the fix needs to be backported to older branches. In this post, I’m going to talk about how I usually do this.
But sometimes there are no specific steps to reproduce available, or it may not be obvious that a bug is a regression. In those cases, when you have a fix for the bug at hand, it would be nice to take a few extra minutes to look at the code that you have modified in the fix to see where the code changes are coming from. This can be done using a blame/annotate source code tool. These tools show which changeset each line of code is coming from. Depending on your favorite revision control system (hg or git) and your favorite source code editor/IDE (Vim, Emacs, Eclipse, VS Code, Sublime, etc.) you can find any number of plugins and many online tutorials on how to view annotated source code. An easy way, and the that I use most of the time these days is looking at annotations through Searchfox. But you may also want to familiarize yourself with a plugin that works with your workflow to assist you in navigating the history of the code.
There are a few helpful links here for following the history of the code. “Show earliest version with this line” is useful to look at the revision of this file which introduced the line you hovered. “Show latest version without this line” is helpful to look at the parent revision of this file with respect to the aforementioned changeset. Using these two links you can navigate backwards in history to get to the point in time when a part of the code was first introduced. Often times you need to walk several steps back in the history before you get to the correct revision since code can be moved around, re-indented, modified in slight ways that don’t matter to you at the time, etc.
Add the regression keyword to the bug if it doesn’t have it already.
Based on the version of Firefox that was first impacted by the bug found in the previous step, under Firefox Tracking Flags, set the Tracking flag for the respective versions to “?”.
Similarly, set the Status flag for the affected versions to “affected”, and for the older version(s) to “unaffected”. Bugzilla will help you fill out a comment section describing why this tracking is needed to the release management team.