This is a collection of guides that should help AMO Engineers and other Mozillians navigate the madness that is the add-ons world.
MDN Doc for add-on types.
||In AMO DB||Notes|
|Dictionary||64||3||| Language for the Firefox spellchecker.|
|Search Engine||N/A||4||| For the Firefox search box. See doc.|
|Language pack||8||5||| Localization for Firefox UI. Most are automatically published from Firefox sources.|
|Complete theme||4||2||| Deprecated. Will be dropped in Firefox 57.|
|Multi-package installer||32||1||| Discontinued.|
WebExtension packages don't have types. They are all treated like extensions, with the exception of new themes (WIP).
The AMO DB has a couple more types that are no longer in use: 7 - Plugins, 6 - Language Packs (Add-on), 11 - Apps.
MDN doc on compatibility for legacy add-ons.
Compatibility with the client depends on various factors. They are listed here in order of priority (next one overrides previous one):
- Default compatibility.
- Legacy add-ons with a
maxVersionlower than Firefox 4.0a1 have strict compatibility, so the
maxVersionmust be respected.
- For all other add-ons, the
minVersionfor legacy add-ons should always be respected.
- WebExtensions have default minimum compatibility of Firefox 42.0a1.
- Application support (Firefox / Thunderbird / SeaMonkey / Android) is read from the manifest and can be altered during submission (All Desktop / Windows / Linux / Mac OS / Android).
- Legacy add-ons with a
- Strict compatibility.
- AMO Metadata (editable in Developer Hub).
- For add-ons with strict compatibility (legacy and WebExtensions) this overrides what is declared in the manifest.
- Application support can also be altered here.
- Compatibility overrides. These are admin overrides that declare a version range for an add-on is not compatible with a version range of an application (usually Firefox).
This doesn't apply to lightweight themes and search engines.
Add-on and File Statuses
This table explains the different add-on and file status combinations during the life cycle of a listed add-on:
|Case||Add-on status||File status (latest listed)||Notes|
|New listed add-on, incomplete submission||Incomplete (0)||Awaiting Review (3)|
|New listed add-on, submitted for review||Awaiting Review (3)||Awaiting Review (3)|
|Rejected after review (no previous approvals)||Incomplete (0)||Disabled by Mozilla (5), all files||| Also when admins want to take down an add-on and let the developer submit a fix.|
|Approved and listed||Approved (4)||Approved (4)|
|Approved, updated submitted||Approved (4)||Awaiting Review (3)||| Previously-approved version appears on listing page.|
|Disabled by an admin||Disabled by Mozilla (5)||Any||| Add-ons in this state can't be accessed by their developer.|
|Deleted||Deleted (11)||No files|
Unlisted versions are submitted and auto-Approved (4) without affecting the add-on status. So, add-ons that are exclusively unlisted have an add-on status of Incomplete (0) and Approved (4) files.
An add-on version can have multiple files, and it used to be possible for them to have a different review status. That's the reason the review status is stored in the file rather than the version. Most if not all cases preventing the status to be moved up to the version are fixed now.
For add-ons with listed versions, Beta (7) is another valid file status. Like unlisted versions, they are submitted and auto-approved. They are listed in the Developer Channel section in the listing page (for example).
A version can be listed or unlisted depending on its
channel, which is set to 1 for Unlisted and 2 for Listed. The channel for a version can't be changed.
A developer can hide their listing page using the
inactive field in the add-on.
Featured Add-ons and Collections