Your system may not meet the requirements for Firefox, but you can try one of these versions:

Your system doesn't meet the requirements to run Firefox.

Your system doesn't meet the requirements to run Firefox.

Please follow these instructions to install Firefox.

Firefox Privacy Notice

Super-Review Policy

The super-reviewers group is a set of senior, experienced hackers who can add value across the codebase in some specific ways separate from domain expertise.

A review from a super-reviewer is required for certain types of changes for all code residing in mozilla-central and comm-central (and all release branches based on those repositories) unless explicitly exempted in the Exceptions section below. Super-review is required in addition to a appropriate module owner or peer review. This means that one reviewer cannot provide both review and super-review on a single patch.

What needs super-review?

Significant architectual refactoring
All changes that involve significant changes to how code works and interacts must be submitted for super-review. Code design is hard, and getting more input helps us in the areas of maintainability.
Any change to any API or pseudo-API
APIs are not just XPCOM APIs, but include global JS utility functions and the like. Designing these better up front makes it easier to build things on top of these APIs, and helps us avoid compatibility-killing “API cleanup” down the road.
All changes that affect how code modules interact
Any other changes that fall outside of the above rules, but affect how two or more code modules function, must have super-review.


Ted Mielczarek is the autoconf module owner for Unix, OS2, and other gmake-friendly platforms. His review is sufficient to get changes to those files checked in.

The NSPR module is mature, stable and has been used in Mozilla antecedents for years. Peer and module owner review is sufficient to get those files checked in.

The JavaScript engine is a self-contained area, with dependencies only on another self-contained area (NSPR). Module owner review suffices to change JS code.

Changes to module PSM require at least one thorough owner/peer review. If the person requesting the change is neither the owner nor a peer, a second person from the group of {PSM owners, PSM peers, super-reviewers} must approve the change. Changes to UI that is shared amongst all Mozilla applications (e.g. error messages, password prompts, information windows, certificate manager) shall be reviewed/approved by the Mozilla Foundation’s User Experience team. Changes to UI in the primary application windows (e.g. Firefox preferences, security button in mail, status bar items) must be reviewed/approved by the respective application UI owners.

SeaMonkey specific changes (suite/ in comm-central) are covered by their own review policy.

Calendar specific changes (calendar/ in comm-central) do not require superreview as detailed by their policy.

In general, a well-owned module may make a request to super-reviewers to be exempt from super-review requirements.

See despot.cgi for more on modules, a.k.a. partitions.

Seeking a super-review?

Make sure the bug has appropriate review(s) and then pick an appropriate super-reviewer for the patch from the list below. Request review from that person using the patch flags on the bug: set the super-review flag to ? and fill in the reviewer’s email address from the following list.

Meet the super-reviewers

Here are the strong hackers enlisted by for universal code review coverage:

  • David Bienvenu (; mailnews)
  • Brendan Eich (; js, catch-all)
  • Benjamin Smedberg (; build, docshell, embedding, ipc, toolkit, xpcom)
  • Boris Zbarsky (; content, docshell, layout, netwerk, uriloader)
  • Mark Banner (; directory, mailnews)
  • Chris Jones (; ipc, layers, plugins, xpcom)
  • Christian Biesinger (; docshell, netwerk, uriloader)
  • David Baron (; content, layout)
  • Dave Townsend (; toolkit, browser)
  • Dan Mosedale (; directory, mailnews)
  • Dan Veditz (; security, xpinstall, catch-all)
  • Gavin Sharp (; browser, toolkit)
  • Peter Annema (; strings, xpfe, SeaMonkey Suite)
  • Jonas Sicking (; content, dom, xslt)
  • Johnny Stenback (; content, docshell, dom, htmlparser, layout, plugins)
  • Josh Aas (; widget, plugins, mac)
  • Kai Engert (; security)
  • Mats Palmgren (; layout, widget)
  • Mike Connor (; services, browser, toolkit)
  • Mike Pinkerton (; Camino, widget)
  • Mounir Lamouri (; content, dom)
  • Blake Kaplan (; caps, content, dom, htmlparser, js, xpconnect)
  • Neil Rashbrook (; composer, xpfe, SeaMonkey Suite)
  • Olli Pettay (; content, dom)
  • Stuart Parmenter (; gfx, widget, image libraries)
  • Peter Van der Beken (; content, dom, xslt)
  • Robert Strong (; browser, toolkit)
  • Robert O’Callahan (; gfx, layout, layers)
  • Mike Shaver (; js, xpcom, xpconnect)
  • Vladimir Vukicevic (; gfx, widget, toolkit, storage, canvas, browser, layers)

Here is the list inverted to index by area, sorting by primary or most-expert reviewer. Super-review does not require domain expertise (module owners and peers supply that, usually), so the areas below are not pigeon-holes — you can solicit a super-review from any reviewer on the list, but using area as a guide will get quicker results in the typical case.

content, layout,,, (content), (content), (content), (layout), (content), (content), (content)
docshell, webshell,,,
event loop
image libraries
xul, xbl
catch-all, when in doubt,