289
edits
Changes
initial cut
<small>[[Thunderbird:Dev|<< Back to Thunderbird Dev page]]</small>
== Beginner's Guide to Hacking Thunderbird ==
So, you think you might want to help out with Thunderbird? Great! What's that? You don't have any idea where to begin? Hopefully this document can help. It's designed to be an introduction to submitting your first patch(es) to the Thunderbird codebase.
=== Getting the right tools ===
Before you can begin, you're going to need several tools setup on your computer.
'''Note:''' Some hackers have found it useful to simply begin by building Thunderbird from source. ([http://gemal.dk/mozilla/build.html Windows Instructions]) If you can do this, you will (almost) automatically have all the right tools to begin hacking. However, since building is a rather complicated process, you may wish to come back to it at a later stage.
You will need:
* [https://bugzilla.mozilla.org/createaccount.cgi A Bugzilla account]
* A jar extract/build tool.
** Most zip utilities are capable of working with .jar files as well. Some may require that you rename .jar files to .zip first
** Windows XP can handle zip files by default but misses some higher-end functions which are necessary to work effectively on Thunderbird. [http://www.filzip.com/ FilZip] is a viable freeware alternative.
* A [http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ current nightly build] of Thunderbird
* A text-editor, who is capable of working with files created on Windows, Linux or Mac OS X.
** Windows users are strongly discouraged from using the Notepad text-editor. Viable freeware alternatives are [http://www.flos-freeware.ch/notepad2.html notepad2] and [http://http://www.pspad.com/ PSPad]. These editors will get you a better view of the code (i.e you will see which braces close which codeblocks, 'if','var' and so on will be bold, among other stuff).
* A program capable of creating DIFF files (Most CVS programs are capable of doing this.)
** Windows users who do not want to install the recommended CVS programm might use [http://gnuwin32.sourceforge.net/packages/diffutils.htm diffutils] from the GnuWin32 project.
* A CVS program (kinda optional, but not really)
'''Linux users''' will find most of these programs available by default with their distro.
'''Windows users''' won't have all of these tools installed by default, but if you have followed the windows build instructions above, you have downloaded the required tools.
=== Hacking! ===
Time to make your first changes to the code.
1.) If you haven't done so already, unzip your current nightly build of Thunderbird and make sure it runs properly. Then close it.
2.) Open the 'chrome' folder inside the folder where you unzipped Thunderbird.
Here you will find a variety of files that create the front-end of the application.
* <tt>classic.jar</tt> - contains many of the css (style) files for the default theme
* <tt>comm.jar</tt> - contains some of the core "communicator" files (you usually won't worry about these.)
* <tt>en-US.jar</tt> - these contain the strings used in the application, translated to English. When using another locale, you may see a different jar
* <b><tt>messenger.har</tt></b> - this is where most of the XUL and JS files for Thunderbird are.
* <tt>newsblog.jar</tt> - contains files specific to blog-reading (rss)
* <tt>toolkit.jar</tt> - the common files shared by all Mozilla toolkit applications (Firefox, Thunderbird, etc). These define common widgets and other useful tools.
3.) Find the messenger.jar file and open it with your jar (zip) tool.
Inside here you will find a <tt>content</tt> folder, with 4 sub-folders
* <tt>branding</tt> - Thunderbird specific branding materials
* <tt>editor</tt> - files for the html editor used to compose mail
* <b></tt>messenger</tt></b> - most front-end files for Thunderbird
* <tt>smime</tt> - files related to smime processing
==== XUL Hacking ====
Our first hack is going to be to add a bit of personalization to Thunderbird. We're going to display a label above the list of folders that reads 'My Folder List.'
4.) The main Thunderbird window lives in the messenger.xul file inside <tt>content/messenger</tt>. Open this file in your text-editor.
5.) Scroll down until you see something that looks like:
<tt>
<vbox id="folderPaneBox" minwidth="100" width="200" persist="collapsed width">
<label id="folderColumnLabel" hidden="true" value="&folderColumn.label;"/>
</tt>
A <tt>vbox</tt> is a box whose items are stacked vertically. And a <tt>label</tt> is exactly what you think it is. For more information on various XUL elements, see [http://developer.mozilla.org/en/docs/XUL_Reference DevMo's XUL Reference].
6.) First, notice that the <tt>hidden="true"</tt> attribute is set, meaning that this label isn't shown by default. For our purposes, we want it shown, so remove that.
7.) Change <tt>value="&folderColumn.label;"</tt> to read <tt>value="My Folder List"</tt>. (The original label has an "&" and a ";" because it is an entity. More on this below.)
Now your line should look like this
<tt><label id="folderColumnLabel" value="My Folder List"/></tt>
Save the messenger.xul file.
8.) Place your new messenger.xul back inside <tt>content/messenger</tt> (overwriting the old one) and close the jar tool.
9.) Restart Thunderbird and notice your new label!
Yay! Great work. You just made your first changes to the code. There's only one problem... remember how we said earlier that all strings live in <tt>en-US.jar</tt>? Well, 'My Folder List' here is living in <tt>messenger.jar</tt> which is bad. Change the line back to <tt>value="&folderColumn.label;"</tt> and restart Thunderbird to make sure you did it correctly. Your (still visible) label will now read "Name".
10.) Unzip <tt>en-US.jar</tt> open the folder <tt>lcoale/en-US/messenger</tt>.
11.) Many of the strings for Thunderbird live in <tt>messenger.dtd</tt> here. Open it in your text editor. '''Note:''' Changes to strings are always made first to the en-US file. Other localizers will then update their files (often only prior to a release) to the new strings. Patches involving string changes/additions/deletions should only change en-US files.
12.) Find the ENTITY named <tt>folderColumn.label</tt> and change its value from 'Name' to 'My Folder List'. Save the file.
13.) Put the new <tt>messenger.dtd</tt> file in your en-US.jar (overwriting the old file) and close the jar tool.
14.) Restart Thunderbird and observe the changes.
Congratulations, this is the proper way to change that string.
==== JS Hacking ====
No hacking introduction would be complete without a 'Hello World' example of some sort. So, here's ours. Start with steps 1-3 above.
4.) The main Thunderbird front-end loading takes place in <tt>msgMail3PaneWindow.js</tt> in the function <tt>OnLoadMessenger()</tt>. Open that file in your text-editor.
5.) Find the <tt>OnLoadMessenger()</tt> function. (You'll need to scroll down somewhat.)
6.) Insert the following (after the '{'):
<tt>alert('Hello World!');</tt>
and save the file.
7.) Place your new msgMail3PaneWindow.js back inside <tt>content/messenger</tt> (overwriting the old one) and close the jar tool.
8.) Restart Thunderbird and observe the 'Hello World!' greeting.
=== Finding a bug to fix===
So, by now you're (hopefully) eager to actually fix some real bugs! You may have come here because you already had a bug you wanted to fix. If so, great! The best bugs to fix are usually the ones that annoy you personally. If not, look at the list of [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Thunderbird&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bgood+first+bug%5D&keywords_type=allwords&keywords=&bug_status=NEW&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= good first bugs]. (This is currently a short list, but all bug-triagers have now been told to start adding to this list on a more regular basis, so expect it to grow.) Pick one that sounds interesting to you.
If you have the proper Bugzilla permissions, please assign the bug to yourself. If not, please post a comment in the bug saying that you are working on it. '''If you stop working on the bug, please say so as well!'''
Submit a comment with the basic outline of how you plan to fix the bug. (Or if you have IRC access, talk about the proposal there.) There is nothing more frustrating than working hard on a patch, only to be told that the reviewer wanted the patch solved in a different way. Make sure that your proposed changes (ESPECIALLY changes to the User Interface) are acceptable before investing your valuable time.
Now, for the hard-work part: Fix the bug. Continue to make changes to your messenger.jar file and test them by restarting Thunderbird. Repeat until the bug is solved.
=== Creating and submitting a patch ===
Wow! You've fixed the bug you were working on? Fantastic! Time to submit a patch so that everyone can enjoy the fruits of your labor. The first thing to recognize is that the files inside messenger.jar are slightly different from the actual source files. In an ideal world, you'll check out the source code and create your patch based on that. If your changes are small however, your reviewer may be willing to accept a chrome patch for the short term. If you plan on submitting several patches, you really need to work from CVS.
1.) Check out the Mozilla source code. See the [http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS DevMo article] for more details on this step.
2.) Open up the relevant files and make the same changes to them that you made to your messenger.jar files.
3.) Use your CVS program's diff utility to create a file that contains information about the files you changed. This is usually done with a command something like
<tt>cvs diff -prU 8 mozilla/mail/ > myPatch.diff</tt>
See the [http://developer.mozilla.org/en/docs/Creating_a_patch DevMo article] for more details on this step.
4.) Go to the bug you've been working on and choose 'Create an Attachment'. Put the path to the file that CVS diff created in the proper box, and give your patch a short title describing your changes. Describe in detail the changes that you've made in the Description box. Check the 'Patch' checkbox under content type.
5.) '''Important:''' Ask for a review! In the dropdown menu next to 'review', choose the '?', since you're asking for the review. In the textbox next to the '?' place the email address of one of the thunderbird developers.
Adequate reviewers can be found on the xxx page.
6.) Wait for the review. If you haven't heard anything in 5 days, please 'poke' the review. (Ideally, talk to them on IRC. At a minimum, post a comment in the bug.) If you haven't heard anything in 10 days, please choose a different reviewer.
7a.) If your review request is '''granted:''' Your reviewer will 'check in' your patch and (in most cases) mark the bug as FIXED. You can use [http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fcvsroot Bonsai] to confirm this. (If he doesn't check it in, add the <code>checkin-needed</code> keyword to the bug, and the checkin monkeys will commit it for you, usually within the next week or two.) Congratulations! You've just fixed your first bug.
7b.) If your review request is '''denied:''' Don't lose heart! This happens more often than not. Your reviewer will tell you changes that need to be made to the patch in order for it to be acceptable for checkin. Repeat this process with those changes in mind, submit another patch, and ask for another review.
==== Tips for making good patches ====
* Comments inside the code are encouraged! Remember, someone else is going to have to go back and read your code later without any clue of what you were thinking when you were doing it. Make sure that this can be done with as little pain as possible
* Don't just fix things, fix them correctly. If you find yourself adding lots of special cases for what seems like a simple task, the patch probably won't be approved without a very good reason. Mozilla code is complicated enough as it is; don't make it more so.
* Be careful about random whitespace changes. Don't add newlines to irrelevant areas, and make sure you remove extra newlines you added while experimenting.
* While alert() (and it's cousin dump()) are useful for debugging, they should not remain in code that will be checked in. Remove any alert()s you may have used for testing.
* Use spaces, NOT tabs.
* Follow the existing style of the document you're working on. If default indenting is 4 spaces, use 4 spaces. If it's 2, use 2. If braces are placed on the same line as <tt>for</tt> and <tt>if</tt> (ie <tt>if (a == b) {</tt>) keep it this way. If they're on the next line, keep it that way.
* Don't be afraid to ask for help!
=== Useful tools ===
* [irc://irc.mozilla.org IRC] - Thunderbird hackers and reviewers like to hang out in the #maildev channel on irc.mozilla.org. They're usually more than happy to answer your questions if you get stuck on a part of a patch. '''Be patient''' when asking questions, though. Hackers have to sleep, eat, and work too, so it may take several hours before someone sees your question and responds.
* [http://lxr.mozilla.org/mozilla/ LXR] - Great for searching the mozilla codebase for examples, particular code lines, etc.
* [http://www.xulplanet.com/ XULPlanet] - a great reference on all things XUL.
* [http://developer.mozilla.org/ DevMo] - The Mozilla Developer's Center. Tons of great links and articles on almost everything Mozilla-hackish imaginable.
* [http://www.geocities.com/gekacheka/moz/tool/venkman/index.html Venkman Javascript Debugger] patched to be usable in Thunderbird
* [http://www.geocities.com/gekacheka/moz/tool/extensiondev/index.html Extension Developer] with Javascript Shell. Patched to be installable in Thunderbird.
=== Useful settings ===
* You can receive [[http://developer.mozilla.org/en/docs/Setting_up_extension_development_environment more debug messages]] with some preference settings.
=== Other possibly useful links ===
*[http://developer.mozilla.org/en/docs/Hacking_Firefox Hacking Firefox Guide]
== Beginner's Guide to Hacking Thunderbird ==
So, you think you might want to help out with Thunderbird? Great! What's that? You don't have any idea where to begin? Hopefully this document can help. It's designed to be an introduction to submitting your first patch(es) to the Thunderbird codebase.
=== Getting the right tools ===
Before you can begin, you're going to need several tools setup on your computer.
'''Note:''' Some hackers have found it useful to simply begin by building Thunderbird from source. ([http://gemal.dk/mozilla/build.html Windows Instructions]) If you can do this, you will (almost) automatically have all the right tools to begin hacking. However, since building is a rather complicated process, you may wish to come back to it at a later stage.
You will need:
* [https://bugzilla.mozilla.org/createaccount.cgi A Bugzilla account]
* A jar extract/build tool.
** Most zip utilities are capable of working with .jar files as well. Some may require that you rename .jar files to .zip first
** Windows XP can handle zip files by default but misses some higher-end functions which are necessary to work effectively on Thunderbird. [http://www.filzip.com/ FilZip] is a viable freeware alternative.
* A [http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ current nightly build] of Thunderbird
* A text-editor, who is capable of working with files created on Windows, Linux or Mac OS X.
** Windows users are strongly discouraged from using the Notepad text-editor. Viable freeware alternatives are [http://www.flos-freeware.ch/notepad2.html notepad2] and [http://http://www.pspad.com/ PSPad]. These editors will get you a better view of the code (i.e you will see which braces close which codeblocks, 'if','var' and so on will be bold, among other stuff).
* A program capable of creating DIFF files (Most CVS programs are capable of doing this.)
** Windows users who do not want to install the recommended CVS programm might use [http://gnuwin32.sourceforge.net/packages/diffutils.htm diffutils] from the GnuWin32 project.
* A CVS program (kinda optional, but not really)
'''Linux users''' will find most of these programs available by default with their distro.
'''Windows users''' won't have all of these tools installed by default, but if you have followed the windows build instructions above, you have downloaded the required tools.
=== Hacking! ===
Time to make your first changes to the code.
1.) If you haven't done so already, unzip your current nightly build of Thunderbird and make sure it runs properly. Then close it.
2.) Open the 'chrome' folder inside the folder where you unzipped Thunderbird.
Here you will find a variety of files that create the front-end of the application.
* <tt>classic.jar</tt> - contains many of the css (style) files for the default theme
* <tt>comm.jar</tt> - contains some of the core "communicator" files (you usually won't worry about these.)
* <tt>en-US.jar</tt> - these contain the strings used in the application, translated to English. When using another locale, you may see a different jar
* <b><tt>messenger.har</tt></b> - this is where most of the XUL and JS files for Thunderbird are.
* <tt>newsblog.jar</tt> - contains files specific to blog-reading (rss)
* <tt>toolkit.jar</tt> - the common files shared by all Mozilla toolkit applications (Firefox, Thunderbird, etc). These define common widgets and other useful tools.
3.) Find the messenger.jar file and open it with your jar (zip) tool.
Inside here you will find a <tt>content</tt> folder, with 4 sub-folders
* <tt>branding</tt> - Thunderbird specific branding materials
* <tt>editor</tt> - files for the html editor used to compose mail
* <b></tt>messenger</tt></b> - most front-end files for Thunderbird
* <tt>smime</tt> - files related to smime processing
==== XUL Hacking ====
Our first hack is going to be to add a bit of personalization to Thunderbird. We're going to display a label above the list of folders that reads 'My Folder List.'
4.) The main Thunderbird window lives in the messenger.xul file inside <tt>content/messenger</tt>. Open this file in your text-editor.
5.) Scroll down until you see something that looks like:
<tt>
<vbox id="folderPaneBox" minwidth="100" width="200" persist="collapsed width">
<label id="folderColumnLabel" hidden="true" value="&folderColumn.label;"/>
</tt>
A <tt>vbox</tt> is a box whose items are stacked vertically. And a <tt>label</tt> is exactly what you think it is. For more information on various XUL elements, see [http://developer.mozilla.org/en/docs/XUL_Reference DevMo's XUL Reference].
6.) First, notice that the <tt>hidden="true"</tt> attribute is set, meaning that this label isn't shown by default. For our purposes, we want it shown, so remove that.
7.) Change <tt>value="&folderColumn.label;"</tt> to read <tt>value="My Folder List"</tt>. (The original label has an "&" and a ";" because it is an entity. More on this below.)
Now your line should look like this
<tt><label id="folderColumnLabel" value="My Folder List"/></tt>
Save the messenger.xul file.
8.) Place your new messenger.xul back inside <tt>content/messenger</tt> (overwriting the old one) and close the jar tool.
9.) Restart Thunderbird and notice your new label!
Yay! Great work. You just made your first changes to the code. There's only one problem... remember how we said earlier that all strings live in <tt>en-US.jar</tt>? Well, 'My Folder List' here is living in <tt>messenger.jar</tt> which is bad. Change the line back to <tt>value="&folderColumn.label;"</tt> and restart Thunderbird to make sure you did it correctly. Your (still visible) label will now read "Name".
10.) Unzip <tt>en-US.jar</tt> open the folder <tt>lcoale/en-US/messenger</tt>.
11.) Many of the strings for Thunderbird live in <tt>messenger.dtd</tt> here. Open it in your text editor. '''Note:''' Changes to strings are always made first to the en-US file. Other localizers will then update their files (often only prior to a release) to the new strings. Patches involving string changes/additions/deletions should only change en-US files.
12.) Find the ENTITY named <tt>folderColumn.label</tt> and change its value from 'Name' to 'My Folder List'. Save the file.
13.) Put the new <tt>messenger.dtd</tt> file in your en-US.jar (overwriting the old file) and close the jar tool.
14.) Restart Thunderbird and observe the changes.
Congratulations, this is the proper way to change that string.
==== JS Hacking ====
No hacking introduction would be complete without a 'Hello World' example of some sort. So, here's ours. Start with steps 1-3 above.
4.) The main Thunderbird front-end loading takes place in <tt>msgMail3PaneWindow.js</tt> in the function <tt>OnLoadMessenger()</tt>. Open that file in your text-editor.
5.) Find the <tt>OnLoadMessenger()</tt> function. (You'll need to scroll down somewhat.)
6.) Insert the following (after the '{'):
<tt>alert('Hello World!');</tt>
and save the file.
7.) Place your new msgMail3PaneWindow.js back inside <tt>content/messenger</tt> (overwriting the old one) and close the jar tool.
8.) Restart Thunderbird and observe the 'Hello World!' greeting.
=== Finding a bug to fix===
So, by now you're (hopefully) eager to actually fix some real bugs! You may have come here because you already had a bug you wanted to fix. If so, great! The best bugs to fix are usually the ones that annoy you personally. If not, look at the list of [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Thunderbird&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=%5Bgood+first+bug%5D&keywords_type=allwords&keywords=&bug_status=NEW&resolution=DUPLICATE&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= good first bugs]. (This is currently a short list, but all bug-triagers have now been told to start adding to this list on a more regular basis, so expect it to grow.) Pick one that sounds interesting to you.
If you have the proper Bugzilla permissions, please assign the bug to yourself. If not, please post a comment in the bug saying that you are working on it. '''If you stop working on the bug, please say so as well!'''
Submit a comment with the basic outline of how you plan to fix the bug. (Or if you have IRC access, talk about the proposal there.) There is nothing more frustrating than working hard on a patch, only to be told that the reviewer wanted the patch solved in a different way. Make sure that your proposed changes (ESPECIALLY changes to the User Interface) are acceptable before investing your valuable time.
Now, for the hard-work part: Fix the bug. Continue to make changes to your messenger.jar file and test them by restarting Thunderbird. Repeat until the bug is solved.
=== Creating and submitting a patch ===
Wow! You've fixed the bug you were working on? Fantastic! Time to submit a patch so that everyone can enjoy the fruits of your labor. The first thing to recognize is that the files inside messenger.jar are slightly different from the actual source files. In an ideal world, you'll check out the source code and create your patch based on that. If your changes are small however, your reviewer may be willing to accept a chrome patch for the short term. If you plan on submitting several patches, you really need to work from CVS.
1.) Check out the Mozilla source code. See the [http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS DevMo article] for more details on this step.
2.) Open up the relevant files and make the same changes to them that you made to your messenger.jar files.
3.) Use your CVS program's diff utility to create a file that contains information about the files you changed. This is usually done with a command something like
<tt>cvs diff -prU 8 mozilla/mail/ > myPatch.diff</tt>
See the [http://developer.mozilla.org/en/docs/Creating_a_patch DevMo article] for more details on this step.
4.) Go to the bug you've been working on and choose 'Create an Attachment'. Put the path to the file that CVS diff created in the proper box, and give your patch a short title describing your changes. Describe in detail the changes that you've made in the Description box. Check the 'Patch' checkbox under content type.
5.) '''Important:''' Ask for a review! In the dropdown menu next to 'review', choose the '?', since you're asking for the review. In the textbox next to the '?' place the email address of one of the thunderbird developers.
Adequate reviewers can be found on the xxx page.
6.) Wait for the review. If you haven't heard anything in 5 days, please 'poke' the review. (Ideally, talk to them on IRC. At a minimum, post a comment in the bug.) If you haven't heard anything in 10 days, please choose a different reviewer.
7a.) If your review request is '''granted:''' Your reviewer will 'check in' your patch and (in most cases) mark the bug as FIXED. You can use [http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=ThunderbirdTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fcvsroot Bonsai] to confirm this. (If he doesn't check it in, add the <code>checkin-needed</code> keyword to the bug, and the checkin monkeys will commit it for you, usually within the next week or two.) Congratulations! You've just fixed your first bug.
7b.) If your review request is '''denied:''' Don't lose heart! This happens more often than not. Your reviewer will tell you changes that need to be made to the patch in order for it to be acceptable for checkin. Repeat this process with those changes in mind, submit another patch, and ask for another review.
==== Tips for making good patches ====
* Comments inside the code are encouraged! Remember, someone else is going to have to go back and read your code later without any clue of what you were thinking when you were doing it. Make sure that this can be done with as little pain as possible
* Don't just fix things, fix them correctly. If you find yourself adding lots of special cases for what seems like a simple task, the patch probably won't be approved without a very good reason. Mozilla code is complicated enough as it is; don't make it more so.
* Be careful about random whitespace changes. Don't add newlines to irrelevant areas, and make sure you remove extra newlines you added while experimenting.
* While alert() (and it's cousin dump()) are useful for debugging, they should not remain in code that will be checked in. Remove any alert()s you may have used for testing.
* Use spaces, NOT tabs.
* Follow the existing style of the document you're working on. If default indenting is 4 spaces, use 4 spaces. If it's 2, use 2. If braces are placed on the same line as <tt>for</tt> and <tt>if</tt> (ie <tt>if (a == b) {</tt>) keep it this way. If they're on the next line, keep it that way.
* Don't be afraid to ask for help!
=== Useful tools ===
* [irc://irc.mozilla.org IRC] - Thunderbird hackers and reviewers like to hang out in the #maildev channel on irc.mozilla.org. They're usually more than happy to answer your questions if you get stuck on a part of a patch. '''Be patient''' when asking questions, though. Hackers have to sleep, eat, and work too, so it may take several hours before someone sees your question and responds.
* [http://lxr.mozilla.org/mozilla/ LXR] - Great for searching the mozilla codebase for examples, particular code lines, etc.
* [http://www.xulplanet.com/ XULPlanet] - a great reference on all things XUL.
* [http://developer.mozilla.org/ DevMo] - The Mozilla Developer's Center. Tons of great links and articles on almost everything Mozilla-hackish imaginable.
* [http://www.geocities.com/gekacheka/moz/tool/venkman/index.html Venkman Javascript Debugger] patched to be usable in Thunderbird
* [http://www.geocities.com/gekacheka/moz/tool/extensiondev/index.html Extension Developer] with Javascript Shell. Patched to be installable in Thunderbird.
=== Useful settings ===
* You can receive [[http://developer.mozilla.org/en/docs/Setting_up_extension_development_environment more debug messages]] with some preference settings.
=== Other possibly useful links ===
*[http://developer.mozilla.org/en/docs/Hacking_Firefox Hacking Firefox Guide]
