Add-on SDK in Firefox
From MozillaWiki
Please use "Edit with form" above to edit this page.
Status
Add-on SDK in Firefox | |
Stage | Draft |
Status | In progress |
Release target | Firefox 15 |
Health | OK |
Status note | ` |
Team
Product manager | ` |
Directly Responsible Individual | Dietrich Ayala (:dietrich) |
Lead engineer | Irakli Gozalishvili (:gozala) |
Security lead | ` |
Privacy lead | ` |
Localization lead | ` |
Accessibility lead | ` |
QA lead | ` |
UX lead | ` |
Product marketing lead | ` |
Operations lead | ` |
Additional members | ` |
Open issues/risks
Open issues:
- Need to ensure Jetpack tests are run per-checkin by default on all branches (where it makes sense)
Stage 1: Definition
1. Feature overview
Ship the Add-on SDK runtime and libraries inside Firefox.
- Meta-bug: bug 731779
- Bi-weekly meetings with the Jetpack Features group
Prior work, notes:
- Notes from Dec 2011 meeting
- Package-oriented proposal from Drew
- Brian Warner currently runs a bridge that syncs the Add-on SDK Git repo with hg.m.o/projects/addon-sdk, based on https://github.com/schacon/hg-git
2. Users & use cases
- Reduced add-on size. Currently add-ons created with the SDK are 200k at a minimum. This reduces download time and installation time of add-ons, streamlining the process.
- Develop core features using the SDK. Firefox core developers can use the SDK libraries to build features.
- Easier to convert add-ons into Firefox features, so prototyping features should be easier.
- Repacking might be simpler, or not required at all
- Scratchpad could be used as an offline version of the Add-on Builder.
- Old school add-ons can more easily leverage features from the add-on sdk, which should help them port older add-ons.
3. Dependencies
- Packageless Jetpack proposal may be a dependency (view)
4. Requirements
- Add-on SDK loader and API libraries are shipped inside Firefox, removing the necessity of packaging them inside each add-on.
- SDK development continues on Github.
- SDK continues to be developed and reviewed by the SDK team.
Non-goals
- Allow runtime resolution of modules.
- Allow sharing of modules across add-ons.
- Allow interdependency at the add-on level.
Stage 2: Design
5. Functional specification
`
6. User experience design
`
Stage 3: Planning
7. Implementation plan
Meta-bug: bug 731779
- Set up Git->HG syncing infrastructure (Non-blocking: If not ready by landing time, can do weekly drops.)
- Work with browser/toolkit module owners to determine code location in each component.
- Land CommonJS loader in Firefox (In toolkit, have Mossop to review.)
- Jetpack housecleaning required before landing
- Misc cleanup (removing window-utils, etc.)
- Packagelessness
- Separate core APIs into Browser and Toolkit sets
- Land core APIs in Firefox
Each of these Loader usage scenarios should be supported and documented with code samples:
- Inclusion into XUL window scope
- Inclusion into non-window scopes (JS XPCOM, JS Modules)
- Support shared & private instances
8. Reviews
Security review
The Add-on SDK has gone through multiple security reviews. Should schedule another one to review how/where the code lives and is initiated/loaded inside Firefox.
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
`
Feature details
Priority | Unprioritized |
Rank | 999 |
Theme / Goal | ` |
Roadmap | ` |
Secondary roadmap | ` |
Feature list | ` |
Project | ` |
Engineering team | ` |
Team status notes
status | notes | |
Products | ` | ` |
Engineering | ` | ` |
Security | sec-review-needed | dveditz assigned |
Privacy | ` | ` |
Localization | ` | ` |
Accessibility | ` | ` |
Quality assurance | ` | ` |
User experience | ` | ` |
Product marketing | ` | ` |
Operations | ` | ` |