Hacking Firefox

  • Revision slug: Hacking_Firefox
  • Revision title: Hacking Firefox
  • Revision id: 46619
  • Created:
  • Creator: Dria
  • Is current revision? No
  • Comment /* Knowing where to ask for help */

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, its 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 instructions here, make sure you use CVS trunk, and get the beast built. 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 CVS, but if you can’t figure it out even with help, you’re probably not ready yet. If 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.)

Picking bugs to work on.

Votes sort of matter. Sort of. Sometimes its 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 soon, DevMo) before you bug real people. If its a “how should the UI look�? question, asking mconnor 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 behaviour that will affect the user experience, it’s best for everyone concerned to get feedback before you start. Talk to Ben, myself, or one of the other Firefox peers, get reaction/adjustments. If we say its a no, you’ve just saved yourself a lot of stress and resentment (based on how people who don’t follow this role have reacted to review- in the past).

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, its 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.
</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="external" href="https://bugzilla.mozilla.org/">Bugzilla</a>. 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.
</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 instructions here, make sure you use CVS trunk, and get the beast built. 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 CVS, but if you can’t figure it out even with help, you’re probably not ready yet. If 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 mozilla/browser and mozilla/toolkit, respectively.)
</p>
<h3 name="Picking_bugs_to_work_on."> Picking bugs to work on. </h3>
<p>Votes sort of matter. Sort of. Sometimes its 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.
</p>
<h3 name="Knowing_where_to_ask_for_help"> Knowing where to ask for help </h3>
<p><span class="plain">#developers</span> 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 soon, DevMo) before you bug real people. If its a “how should the UI look�? question, asking mconnor or another Firefox peer 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 behaviour that will affect the user experience, it’s best for everyone concerned to get feedback before you start. Talk to Ben, myself, or one of the other Firefox peers, get reaction/adjustments. If we say its a no, you’ve just saved yourself a lot of stress and resentment (based on how people who don’t follow this role have reacted to review- in the past).
</p>
Revert to this revision