DOM/Engineering

Disclaimer: This document is currently just in its infancy.

This page attempts to serve as a cheat-sheet for the things DOM engineers may do by linking to the documentation on how to do it or calling out where we need more documentation. We try and transcend being a list of links by contextualizing the links and inlining and deep-linking when the target link is more than a page. For example, while there are other pages that capture the many test frameworks, readers should be able to ctrl-f for "reftest" and get a brief definition of what a reftest is and from there a link to more details.

Please feel free to edit to make the document more usable.

Building Firefox

Making Builds Go Faster

• You can use Icecream to distribute builds to other machines on whatever network you're using. Each Mozilla office has its own build server you can use. If you work remotely, you can also see massive speed-ups from adding a second comparable machine.
• You can use ccache in conjunction with ice cream. ccache caches deterministic build results which is useful when the only thing that has changed for a file are the timestamps of its dependencies.

Spec-Work

Communication: Participate in Spec Development

• Listen and participate.
  • Watch the github repo.
  • Join the mailing list.

Mechanics: WebIDL

WebIDL (spec), or the Web Interface Definition Language, defines the APIs that Firefox exposes to JavaScript content.

Understanding

Doing

Mechanics: Testing

There are two broad categories of tests you'll deal with.

• Web Platform Tests are cross-browser tests. The contents of testing/web-platform-tests are periodically automatically synchronized to/from the github repo at https://github.com/web-platform-tests/wpt.
• Firefox specific tests. There are actually a number of

Bugs

Handling Reported Bugs

• Be aware of what's going on:
  • Watching: Bugzilla has a number of "watching" mechanism to help you track what's going on via email.
    • You can opt to receive bugmail for all activity in a given component without being CC'ed on the bug via the preferences' Component Watching preferences page. While this is useful, it can be a bit much. Messages you receive because you're watching a component will have an "X-Bugzilla-Reason" header value of "None" that you can use to filter on to differentiate from reasons like "CC". "X-Bugzilla-Watch-Reason" will also include "Component-Watcher" in that case among its other space-delimited terms.
    • You can also watch what your team-mates are doing by using the "User Watching" functionality on the Email Preferences preferences page. "X-Bugzilla-Reason" will be "None" in this case just like for component watching, but you can filter using "X-Bugzilla-Who" which will be the email address of the watched person, as well as "X-Bugzilla-Watch-Reason" which will also include their email address and terms that identify their relation to the bug such as "AssignedTo" and "CC" separated by spaces.
  • Triage: However, that all can get a bit overwhelming. You don't need to read every bug that comes into your mailbox. Which is why we have a triage process for components. Triagers will go through un-triaged bugs in a component and evaluate them and set a needinfo flag or assignee to take next steps to deal with the bug.

Security Bugs

• https://wiki.mozilla.org/Security_Severity_Ratings
• https://wiki.mozilla.org/Security/Bug_Approval_Process
• null pointer crashes should be fixed but don't need the whole process.

Using crash-stats.mozilla.org and crash reports

There's a variety of information on how to understand a crash report:

• MDN's Understanding Crash Reports Page

You can also be granted privileges after agreeing to privacy guidelines in order to download Windows-style "minidump" files created by breakpad that contain more details than can be found on the public crash report page. The information includes details like the contents of stack memory (which may include data that has privacy implications, hence the privacy agreement).

• MDN's Debugging a minidump page

Debugging

General links:

• MDN Debugging Page

Remote Debugging of Firefox

Firefox's local debugging APIs can also be accessed remotely. This can be useful for debugging mobile versions of Firefox.

Logging

MOZ_LOG

Improving upon the prior NSPR logging mechanism exposed via NSPR_LOG_MODULES, C++ code can perform conditional logging at a granular per-"module" basis using MOZ_LOG that can be enabled several ways:

• When launching Firefox via the MOZ_LOG environment variable without output going to stdout by default, or a file if MOZ_LOG_FILE is specified.
  • ex: MOZ_LOG=IndexedDB:5 enables verbose IndexedDB logging.
• While Firefox is running via the about:networking page.
• Using preferences by modifying the preferences file when Firefox is not running, or at runtime using "about:config".
  • An int pref "logging.IndexedDB" with a value of 5 enables verbose IndexedDB logging.
  • A string pref "logging.IndexedDB" with a value of "verbose" enables verbose IndexedDB logging. Valid values are "error", "warning", "info", "debug", and "verbose" in order of increasing detail/spamminess.

More info:

• MDN's Gecko Logging page covers how to use the logging mechanism in your code and how to enable it.
• MDN's HTTP Logging page documents the about:networking page that makes it possible to enable and configure