Firefox Developer Onboarding Tips

Lets turn down the firehose a little for someone getting started. You can't absorb all of Mozilla Developer Network before you start coding. Lets help others get started, by describing things we found helpful to get started.

Everyone has their own learning process, so lets make this a place for everyone's learning ideas and opinions.

Contribute to this page by telling others:

• What were good resources for you?
  • critical links you must read
  • techniques that will help you get more productive
  • stuff you got stuck on that you think others will get stuck on
• What is a good order to learn things?
  • technologies you should know first
  • stuff you can learn as you go
  • stuff you wish you did first, second, third
• Your learning experiences when you started.
  • Put your developer onboarding advice here or link out to your blog, perhaps describing your first few weeks.

Where to Ask Questions

• ask.mozilla.org. It is new, but still an excellent place for questions.
• IRC channels (fill in link for this)

Advice from the Pros

• Josh Matthews has a great intro to Gecko development: http://www.joshmatthews.net/fosdem

Testing

• Josh's presentation has some slides to get you familiar with testing lingo (xpcshell, mochitest)
• Ehsan has a more detailed overview of Firefox Testing

Garvan's Gecko Onboarding Tips

Baby Steps

• codefirefox.com
  • A series of ~5 min videos covering getting started on the codebase
  • The single most important thing for me. My favorite vids: mercurial queues and submitting patches. My prior hg experience was minimal, so this really helped get me up to speed quickly.

• Getting the code and compiling
  • Refer to pages for pulling the code, setting up a mozconfig, building with mach build. I can't say I had any problems with this area. I make sure to enable debugging, and disable optimization. You pull, you ./mach build, you ./mach run. Tip: on Linux platforms with python3 as the default, you 'python2 mach build'.
  • You will be pulling mozilla-central. You don't push to this directly, you submit patches to bugs.
  • hg pull -u && ./mach build => a thing to do periodically when you are stepping away for a bit

• Debugging the code
  • I am on OS X, using LLDB. Wasted a ton of time because I didn't read the tip about setting the right lldb init. The build process uses unified sources (concat cpp files together to reduce # of object files and speed up the build).
  • On my own code, I would prefer to just read through it, but on a large confusing codebase -I can think of one :)- I need to step through code, and I need to run it and print functions that are being hit, and try to visualize how the pieces fit together. I don't have time for printf and build, and I don't like setting tons of breakpoints in gdb that print when I know how quickly I can do this in an IDE. I use Xcode a lot for this.

• Editing code
  • This is an individual preference. Most use Emacs or Vim. I switch between MacVim and JEdit, but code mostly in Xcode, because I have worked with it since 1.x.
  • Browsing/Searching the code base, mxr and dxr (same thing, 2 approaches). I don't go a day without using these, even though I have code indexing in Xcode.

• Try Server
  • The answer to the question: How do I test my local changes?
  • You will test your code to see if compiles and passes the tests using this. You will need to sign a document to get access (to submit it I took a picture).
  • Once you are comfortable, I use a wee script for this (I would try in batches, so I'll change the Try request from time to time).
  • I use the TryChooser Syntax Builder to create the try string.