Hacking Firefox

  • Revision slug: Hacking_Firefox
  • Revision title: Hacking Firefox
  • Revision id: 46638
  • Created:
  • Creator: wangze500
  • Is current revision? No
  • Comment no changes; page display name reset to default

Revision Content

 

If you are a C++ god, this isn't for you. I might even go so far as to say that hacking front-end code isn't the right place for you, but we could always use extra eyes and hands building up the platform. Hacking the front end requires not only coding skill, but instinct for user interface and a very, very thick skin. However, it's relatively easy to poke around the front end. Knowing enough C++/JavaScript/XML basics to find your way around is a good start, without even delving into XPCOM and friends. First things first, of course.

Start with the basics

Before you start to try and hack, you need to learn how to get around Bugzilla. Triage/QA/searching bugs for a couple weeks or longer is a good minimum requirement before you think "hey, I want to hack Firefox". Discovering how the project works, learning to sift for what matters, and applying lessons learned in the initial triage process will go a long way to finding your way through reviews and checkin. Picking something you find randomly isn't usually the best thing to start with. Seeing what's well-owned and what needs extra attention is also a good starting point for hacking.

Build the Fox

I could rehash what’s been better-written by others, but I won't. Start with the generic build instructions, make sure you use Mercurial (hg), and get the beast built. Prefer tinkering with Firefox 3/Mozilla 1.9 and earlier? use CVS.  You need to be able to make this work before you attempt to take the next step. Yes, it isn’t trivial to build anything from Mozilla Mercurial, but if you can't figure it out even with help, you're probably not ready yet. I can go from "never compiling anything" to "building on Win32" in an hour or so.

Source code organization

The next problem is "where does the app/front-end code live?" Firefox-specific code lives here, and generic FE toolkit code lives here. (In your CVS tree, it would be mozilla/browser and mozilla/toolkit, respectively.)

Text file format

Some editors store a UTF-8 Byte Order Marker (BOM) at the beginning of source files by default. This UTF-8 character (0xEF 0xBB 0xBF) can interfere with various tools used by the Mozilla project, so you need to be sure you save your files without a BOM.

If you have files that already have BOM characters, you need to remove them, either using your text editor, or by using a script such as the following:

# nukebom.pl 
$INC{ "bytes.pm" }++ if $] < 5.006;
use bytes;

s/^\xEF\xBB\xBF//s;

You can execute this script with the command perl -pi nukebom.pl filename.

Picking bugs to work on

Votes matter. Sort of. Sometimes it's a simple matter to make it happen too, and if there's low-hanging fruit, pick it. Other times, bugs with "good first bug" in the status whiteboard are good places to go to find your way around. And, of course, stuff that annoys you is good too. Lots of good personal satisfaction involved there.

Knowing where to ask for help

#developers on the Mozilla IRC server is a good place to start if you can't figure it out on your own. But exhaust other resources first, like lxr/bonsai/Google (and this wiki) before you bug real people. If it's a "how should the UI look" question, asking Mike Connor or another Firefox peer is probably your best plan, unless you're ready to argue your case.

Changing the user experience

If you're thinking of implementing a feature request, or changing behavior that will affect the user experience, it's best for everyone concerned to get feedback before you start. Talk to Mike Connor or one of the Firefox peers, and get reaction or adjustments. If they say its a no, you've just saved yourself a lot of stress and resentment (based on how people who don’t follow this rule have reacted to review- in the past).

{{ languages( { "it": "it/Hacking_Firefox", "ja": "ja/Hacking_Firefox" } ) }}

Revision Source

<p> </p>
<p>If you are a C++ god, this isn't for you. I might even go so far as to say that hacking front-end code isn't the right place for you, but we could always use extra eyes and hands <a class="external" href="http://www.mozilla.org/contribute/hacking/first-bugs/">building up the platform</a>. Hacking the front end requires not only coding skill, but instinct for user interface and a very, very thick skin. However, it's relatively easy to poke around the front end. Knowing enough C++/<a href="/en/JavaScript" title="en/JavaScript">JavaScript</a>/<a href="/en/XML" title="en/XML">XML</a> basics to find your way around is a good start, without even delving into <a href="/en/XPCOM" title="en/XPCOM">XPCOM</a> and friends. First things first, of course.</p>
<h3 name="Start_with_the_basics">Start with the basics</h3>
<p>Before you start to try and hack, you need to learn how to get around <a class="link-https" href="https://bugzilla.mozilla.org/">Bugzilla</a>. Triage/<a href="/en/QA" title="en/QA">QA</a>/searching bugs for a couple weeks or longer is a good minimum requirement before you think "hey, I want to hack Firefox". Discovering how the project works, learning to sift for what matters, and applying lessons learned in the initial triage process will go a long way to finding your way through reviews and checkin. Picking something you find randomly isn't usually the best thing to start with. Seeing what's well-owned and what needs extra attention is also a good starting point for hacking.</p>
<h3 name="Build_the_Fox">Build the Fox</h3>
<p>I could rehash what’s been better-written by others, but I won't. Start with the generic build <a class="internal" href="/En/Developer_Guide/Build_Instructions" title="En/Developer Guide/Build Instructions">instructions</a>, make sure you use <a class="internal" href="/En/Developer_Guide/Source_Code/Mercurial" title="en/Mozilla Source Code (Mercurial)">Mercurial (hg)</a>, and get the beast built. Prefer tinkering with Firefox 3/Mozilla 1.9 and earlier? use <a class="internal" href="/En/Developer_Guide/Source_Code/CVS" title="En/Developer Guide/Source Code/CVS">CVS</a>.  You need to be able to make this work before you attempt to take the next step. Yes, it isn’t trivial to build anything from Mozilla Mercurial, but if you can't figure it out even with help, you're probably not ready yet. I can go from "never compiling anything" to "building on Win32" in an hour or so.</p>
<h3 name="Source_code_organization">Source code organization</h3>
<p>The next problem is "where does the app/front-end code live?" Firefox-specific code lives <a class="external" href="http://lxr.mozilla.org/mozilla/source/browser/">here</a>, and generic FE toolkit code lives <a class="external" href="http://lxr.mozilla.org/mozilla/source/toolkit/">here</a>. (In your CVS tree, it would be <code>mozilla/browser</code> and <code>mozilla/toolkit</code>, respectively.)</p>
<h3 name="Text_file_format">Text file format</h3>
<p>Some editors store a UTF-8 Byte Order Marker (BOM) at the beginning of source files by default. This UTF-8 character (0xEF 0xBB 0xBF) can interfere with various tools used by the Mozilla project, so you need to be sure you save your files without a BOM.</p>
<p>If you have files that already have BOM characters, you need to remove them, either using your text editor, or by using a script such as the following:</p>
<pre class="eval"># nukebom.pl 
$INC{ "bytes.pm" }++ if $] &lt; 5.006;
use bytes;

s/^\xEF\xBB\xBF//s;
</pre>
<p>You can execute this script with the command <code>perl -pi nukebom.pl <em>filename</em></code>.</p>
<h3 name="Picking_bugs_to_work_on">Picking bugs to work on</h3>
<p>Votes matter. Sort of. Sometimes it's a simple matter to make it happen too, and if there's low-hanging fruit, pick it. Other times, <a href="/https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&amp;status_whiteboard=[good+first+bug]&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED" title="https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&amp;status_whiteboard=[good+first+bug]&amp;bug_status=NEW&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED">bugs with "good first bug" in the status whiteboard</a> are good places to go to find your way around. And, of course, stuff that annoys you is good too. Lots of good personal satisfaction involved there.</p>
<h3 name="Knowing_where_to_ask_for_help">Knowing where to ask for help</h3>
<p><span class="nowiki">#developers</span> on the <a class="link-irc" href="irc://irc.mozilla.org">Mozilla IRC server</a> is a good place to start if you can't figure it out on your own. But exhaust other resources first, like lxr/bonsai/Google (and this wiki) before you bug real people. If it's a "how should the UI look" question, asking Mike Connor or another <a class="external" href="http://www.mozilla.org/projects/firefox/review.html">Firefox peer</a> is probably your best plan, unless you're ready to argue your case.</p>
<h3 name="Changing_the_user_experience">Changing the user experience</h3>
<p>If you're thinking of implementing a feature request, or changing behavior that will affect the user experience, it's best for everyone concerned to get feedback before you start. Talk to Mike Connor or one of the <a class="external" href="http://www.mozilla.org/projects/firefox/review.html">Firefox peers</a>, and get reaction or adjustments. If they say its a no, you've just saved yourself a lot of stress and resentment (based on how people who don’t follow this rule have reacted to <em>review-</em> in the past).</p>
<p>{{ languages( { "it": "it/Hacking_Firefox", "ja": "ja/Hacking_Firefox" } ) }}</p>
Revert to this revision