Contributing a Mozilla Firebird Patch

Album Cover: Vitalogy

"Wait for signs, believe in lies, to get by, it's divine."
Pearl Jam / Tremor Christ

Posted on October 13, 2003 8:31 PM in Browsers
Warning: This blog entry was written two or more years ago. Therefore, it may contain broken links, out-dated or misleading content, or information that is just plain wrong. Please read on with caution.

I finally got around to submitting my first patch to Mozilla Firebird tonight. The patch addresses a bug (or more appropriately, a work item) submitted back in December of last year that points out that the "Close Tab" icon does not have a pop-up tooltip like other UI buttons do.

My patch is anything but impressive, given that I simply took the work of another developer and applied it to Firebird's more recent code. However, it's my first patch and I'm proud of it, okay? ;) Those who know anything about the Mozilla patch process, though, know that submitting a patch is only the first in a series of steps required to fix a bug. Now a module owner (likely someone who works a lot with the Firebird user interface) will review the patch, making sure it fixes the problem and doesn't introduce any others, and then a super-reviewer will review the patch again. If the patch meets the requirements of both reviewer and super-reviewer, it will likely make its way into the Firebird source code via a CVS check-in.

Because I am relatively new to Mozilla development, even something simple like submitting a patch had a learning curve. There is surprisingly little documentation on the web that goes into the specifics of contributing code and/or fixes to Mozilla and Mozilla Firebird. Therefore, I will post the details of what I went through here so future code-tinkerers won't have to try as hard to find help.

First, I modified the files that needed to be changed in order to fix the bug. In the case of this bug, titled "Close button in the tab bar has no tooltip," I made changes to three files in all. Typically this would be the hardest part, but in my case submitting the patch in Bugzilla was the hardest part. I did a little research, though, and figured out how to create the patch files that you typically see in Bugzilla.

If all your changes reside in the same directory, creating the patch file is relatively simple. However, if the changes reside in different parts of the tree, you'll need to use the following command more than once:

/mozilla/directory> cvs diff -up > /output/filename

If you use the above command, setting directory to the directory you made changes in (or a higher directory in the file structure) and output filename to the file you want to output the patch content to, you'll create yourself a patch. It should also be noted that Mozilla recommends using "cvs diff -u" to create the patch, but I have not verified this method.

Because I had to change several files, one of which was in a separate directory from the others, I ended up creating two patch files and then copying and pasting the contents of one into the other. That way, I had a single patch file that contained the details of all the changes I made to the source. At that point, I was able to submit the patch to Bugzilla and now I wait for the approprite reviewers to take a look and, hopefully sooner than later, check the changes into CVS. Then, if all goes well, whenever you hover over the "Close Tab" button in Firebird and see the tooltip that pops up, you can think of me ;)

I will surely be adding more patches as I get more free time, so if you're reading this and still don't quite have a grasp on how to submit a patch, feel free to contact me. I should also note that this post assumes you already have a firm grasp on building Firebird and hacking the Mozilla source code.


No one has added any comments.

Post Comments

If you feel like commenting on the above item, use the form below. Your email address will be used for personal contact reasons only, and will not be shown on this website.


Email Address:



Check this box if you hate spam.