Features/Jetpack/Simplify the Add-on SDK

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Simplify the Add-on SDK
Stage Development
Status In progress
Release target `
Health OK
Status note Various work in progress


Product manager David Mason
Directly Responsible Individual Irakli Gozalishvili
Lead engineer `
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members `

Open issues/risks


Stage 1: Definition

1. Feature overview

The Add-on SDK's interfaces (APIs, commands, the required structure for an addon) and implementations are overcomplex in a variety of ways, leading to a higher barrier to entry for new developers, a more difficult developer experience, and a greater risk of bugs than is necessary.

Simplicity is a characteristic of product features, but, like performance and certain other such characteristics, it can also be treated as a feature in and of itself, because the overall simplicity of a software product impacts its usability and quality.

This feature is to simplify the SDK's interfaces and implementations to the degree possible in a variety of ways, including:

  • merge bootstrap.js and components/harness.js, dropping attempts at ff3.6/gecko1 compatibility
  • merge cuddlefish.js and securable-module.js, breaking code that does require("cuddlefish") for other purposes (sub-loaders? control over loading process?)
  • build a XPI for 'cfx run' and 'cfx test' too, reducing the number of supported code paths from two to one
  • enable the main addon code and the addon's own HTML pages to communicate directly with each other (rather than having to communicate though a content script)
  • remove package abstraction for SDK's own APIs, moving their code to top-level lib/, doc/, and test/ directories
  • support putting all addon files into a single top-level directory for simple addons that don't have enough files to justify breaking them up into data/, lib/, and test/ subdirectories
  • resolve relative and root-relative text strings passed to URL parameters relative to the location of the script and top-level addon directory for all URL parameters, respectively, so addons can specify "/data/foo.txt" in place of require("self").data.url("foo.txt")
  • require in content scripts?
  • Remove some generalization code contained in the python portions of the SDK

2. Users & use cases

The target audience is addon developers. The use case is an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) to build an addon.

3. Dependencies


4. Requirements




Stage 2: Design

5. Functional specification


6. User experience design


Stage 3: Planning

7. Implementation plan

Many of the items listed in the overview will begin in conjunction with our P1 work so developers do not have to devote 100% of their time to just one feature. Therefore, the status of this full-set feature will be in progress until all items are completed or determined to be part of another feature, or no longer needed or wanted.

8. Reviews

Security review


Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation


Stage 5: Release

10. Landing criteria


Feature details

Priority P2
Rank 999
Theme / Goal `
Roadmap Jetpack
Secondary roadmap `
Feature list Jetpack
Project `
Engineering team Jetpack

Team status notes

  status notes
Products ` `
Engineering ` `
Security pass `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `