Fixing a Bug

Search…
Fixing a Bug
Tutorial on how to fix a bug from beginning to end.
All the issues, bugs, work in progress patches, or updates related to Thunderbird, are listed on Bugzilla, and are properly organized per Product, Component, and Status.
Create a Bugzilla Account
Creating an account is necessary in order to submit patches, leave comments, and interact with any other aspect of Bugzilla. If you're currently using a username in one of our Matrix chat rooms (e.g. #maildev), we recommend saving your profile name with the current format Firstname Lastname (:username) in order to be easily searchable and allow the Thunderbird team to offer better support.
Find a Bug
Use the Advanced Search section to find bugs you want to take care of, and be sure that the bug doesn't currently have any user listed as Assignee and the Status is set to NEW.
Search for Code References
Making sense of the Thunderbird source code, and knowing where to look, will take some time. The code base is pretty big and if you never worked with XBL or Custom Elements it can be overwhelming at first. We recommend using our code search engine, SearchFox, to inspect the source code and find snippets and references to help you out while investigating a bug.
Debugging Core Code
JavaScript code can be debugged using the built-in developer tools toolbox. Debugging core C++ code requires external tools.
Creating Patches
Configuring Mercurial
To ensure your work is correctly attributed to you, and to make the reviewer's task easier, these options should be set in your Mercurial configuration file (Mecurial.ini on Windows, $HOME/.hgrc elsewhere).
[ui]
username = Your Name <[email protected]>
​
[diff]
git = 1
showfunc = 1
unified = 8
Mercurial Workflows
Mercurial is pretty flexible in terms of allowing writing your own code and keeping it separate from the main code base. Based on your knowledge level and preference, you can choose between two different methods:
​Using Queues​
​Using Bookmarks​
The majority of the Thunderbird developers use queues as they're easy to import and export, and avoid merging issues while pulling updates from upstream. For a first time contributor, bookmarks may be easier to get you started, but do not work well when working with multiple patches.
Commit messages
The commit message should be of the form:
Bug xxxx - Short description of your change. r=reviewer
​
Optionally, a longer description of the change.
This can span multiple lines.
Prefixing the first line of the commit message with "WIP:" marks the patch as a work-in-progress. moz-phab (see below) will pick that up and mark it as "Changes Planned".
Picking reviewers
All changes need to be reviewed before acceptance into the codebase. It can be pretty tricky to figure out who to ask for a review.
Thunderbird code is divided into modules, each with an owner and peers. Generally, these are the best people to review your changes. Here's the list of module owners and peers for Thunderbird. Calendar and MailNews Core modules have separate lists.
Scanning through the recent commits in mercurial should also give you an idea of who is active in various areas of the code. Failing that you can always ask around.
Submitting a Patch
The preferred way to submit a patch is via Phabricator.
There is a command line tool, moz-phab, which makes it easy to submit local changesets as patches.
See the moz-phab setup and installation docs.
With moz-phab you can submit local mercurial changeset(s) like this:
$ moz-phab submit [start_changeset] [end_changeset]
The start/end changesets are optional. If omitted, moz-phab will guess which one(s) you mean.
It'll ask for confirmation before uploading, so don't worry too much about accidental submissions.
moz-phab will pick the bug number out of the commit message (Bug xxxx), and link back to the bugzilla bug. If there is a reviewer (r=...), it will automatically assign them and send them a notification. You can leave the reviewer out, but then one will have to be manually assigned via the phabricator web page. If the commit message starts with "WIP:", the patch will be marked "Changes Planned".
You can find more details in the moz-phab README.
Submitting patches via Bugzilla
The traditional way to submit patches was to upload a file attachment to the bug in Bugzilla, set the review flag to ?, and pick a reviewer.
This still works, but Phabricator is now the preferred method.
Updating patches
It's very common for patches to require some updates before being accepted. Locally, you can use hg commit --amend to update a changeset.
Phabricator tracks uploaded patches by adding a line to the commit message:
Differential Revision: <url>
When you submit the patch again with moz-phab, it will see that line and realise that you're updating an existing revision rather than creating a brand new one.
If you're juggling and merging local changesets with hg histedit, make sure you preserve the Differential Revision: line in the commit message for any patches you're planning to resubmit!
Thunderbird Live Development Videos
Using Mercurial Queues
Last modified 10mo ago
Export as PDF
Copy link
Edit on GitHub
Outline
Create a Bugzilla Account
Find a Bug
Search for Code References
Debugging Core Code
Creating Patches
Configuring Mercurial
Submitting patches via Bugzilla
Updating patches