DevTools/Hacking

Want to work on Firefox Developer Tools? You've come to the right place! If you want more information about contributing, check out our guide for getting involved.

Building, running, updating and rebuilding

These instructions have been moved to https://devtools-html.github.io/docs/building.html

Configuring your dev profile

These instructions have been moved to https://devtools-html.github.io/docs/building-development-profile.html

Developer Tools Directories Overview

This has been migrated to https://dxr.mozilla.org/mozilla-central/source/devtools/docs/files/README.md

DevTools Automated Tests

The contents of this section have been moved to https://dxr.mozilla.org/mozilla-central/source/devtools/docs/tests/README.md and other files in https://dxr.mozilla.org/mozilla-central/source/devtools/docs/tests/

Debugging Intermittent Test Failures

When a test fails sometimes, but not always, it is called an "intermittent". Handling these is complicated enough that we have a separate page with tips on debugging.

Finding documentation

If you read through the source code about something you do not know about, you may find documentation here:

• Mozilla Developer Network has a ton of info about XUL elements, HTML, JS, DOM, Web APIs, Gecko-specific APIs, and more.
• DXR is a source code search engine - search for symbols you want to learn about, eg. nsIDocument.
• There's some technical DevTools documentation in the repository that you should check.
• And other technical documents on on this wiki

We recommend adding a smart keyword search for DXR and MDN. If you still have questions, ask us on IRC or leave a comment on the Bugzilla ticket.

Making and Submitting a Patch

Before you make any changes, read the documentation on how to use Mozilla's version control.

Before you submit a patch, you should read our Coding Standards and run ESLint to validate your code changes (to avoid loosing time during code reviews with formatting details for instance). In general, try to be File Consistent. For new files, follow the standards.

Once you have a patch file, add it as an attachment to the Bugzilla ticket you are working on and add the feedback? or review? flag depending on if you just want feedback and confirmation you're doing the right thing or if you think the patch is ready to land respectively. Read more about how to submit a patch and the Bugzilla review cycle here.

You can also take a look at the DevTools/Code Review Checklist as it contains a list of checks that your reviewer is likely to go over when reviewing your code.

Coding Standards

DevTools has some coding standards that your changes should follow:

• JavaScript coding standards
• CSS tips
• SVG Best practices and guidelines for creating new DevTools SVGs

Potential Pitfalls

Today there are a few techniques and conventions we use that can be confusing, especially when you first start working with the code base. We hope to improve these with time to make things easier for everyone, but for now this etherpad might be a helpful set of notes if you are having trouble. If you find new pitfalls that aren't listed there, feel free to add your own entries, so we know to address them. Also, please come talk to us in #devtools on IRC, as that might be the fastest path to solving the issue.