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.

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

• Investigating