Status
| SDK Support for Firefox for Mobile Addons | |
| Stage | Draft |
| Status | ` |
| Release target | TBD |
| Health | OK |
| Status note | Investigating as part of post-1.0 planning |
{{#set:Feature name=SDK Support for Firefox for Mobile Addons
|Feature stage=Draft |Feature status=` |Feature version=TBD |Feature health=OK |Feature status note=Investigating as part of post-1.0 planning }}
Team
| Product manager | David Mason |
| Directly Responsible Individual | David Mason/Myk Melez |
| Lead engineer | ` |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=David Mason
|Feature feature manager=David Mason/Myk Melez |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Firefox for Mobile (FFM) is a high priority for the Mozilla project, we expect it to attract a significant number of users, and we think FFM users are just as interested in customizing their browsing experience using addons as Firefox for Desktop (FFD) users.
FFM addons also support the [Mozilla Manifesto] principle that individuals "have the ability to shape their own experiences on the Internet."
And FFM addons help support the minimalist design philosophy of Firefox by allowing developers to build and users to use browser features that aren't part of the core product.
Thus FFM addons are as important as FFD addons. So it is just as important for the new addon platform provided by the SDK to support building addons for FFM.
Ideally, addons built using the SDK's high-level APIs should work on both FFD and FFM by default without requiring addon developers to specifically target mobile devices, f.e. high-level APIs that enable addons to introduce chrome elements should adapt those elements to the FFM and FFD interfaces.
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 for FFM, FFD, or both browsers.
3. Dependencies
The feature may depend on landing support for specific interface elements in the FFM interface. It may also depend on support for OOP addons, or at least on support for loading content scripts in separate processes, since FFM loads content in a separate process.
4. Requirements
The feature must load an addon built using the SDK in both FFD and FFM. It should make addons that use only the high-level APIs provided by the SDK work by default on both FFD and FFM, although it may require addons to provide browser-specific code if it is not possible to make all APIs "just work" in both browsers.
It must enable an addon to determine which browser the addon is loaded in.
It may provide additional API features that are specific to mobile devices.
Non-goals
`
Stage 2: Design
5. Functional specification
Phase One
Make it possible to load a simple addon that uses no high-level APIs in FFM.
Phase Two
Identify and resolve test failures in high-level APIs (and their low-level dependencies) one-by-one until all SDK tests pass when run against FFM.
Phase Three
Design and implement optimal FFM interface affordances for SDK APIs like Widget and Panel that modify Firefox chrome.
Phase Four
Design and implement additional API features for capabilities that are specific to mobile devices.
6. User experience design
`
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=Firefox for Mobile (FFM) is a high priority for the Mozilla project, we expect it to attract a significant number of users, and we think FFM users are just as interested in customizing their browsing experience using addons as Firefox for Desktop (FFD) users.
FFM addons also support the [Mozilla Manifesto] principle that individuals "have the ability to shape their own experiences on the Internet."
And FFM addons help support the minimalist design philosophy of Firefox by allowing developers to build and users to use browser features that aren't part of the core product.
Thus FFM addons are as important as FFD addons. So it is just as important for the new addon platform provided by the SDK to support building addons for FFM.
Ideally, addons built using the SDK's high-level APIs should work on both FFD and FFM by default without requiring addon developers to specifically target mobile devices, f.e. high-level APIs that enable addons to introduce chrome elements should adapt those elements to the FFM and FFD interfaces. |Feature users and 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 for FFM, FFD, or both browsers. |Feature dependencies=The feature may depend on landing support for specific interface elements in the FFM interface. It may also depend on support for OOP addons, or at least on support for loading content scripts in separate processes, since FFM loads content in a separate process. |Feature requirements=The feature must load an addon built using the SDK in both FFD and FFM. It should make addons that use only the high-level APIs provided by the SDK work by default on both FFD and FFM, although it may require addons to provide browser-specific code if it is not possible to make all APIs "just work" in both browsers.
It must enable an addon to determine which browser the addon is loaded in.
It may provide additional API features that are specific to mobile devices. |Feature non-goals=` |Feature functional spec=Phase One
Make it possible to load a simple addon that uses no high-level APIs in FFM.
Phase Two
Identify and resolve test failures in high-level APIs (and their low-level dependencies) one-by-one until all SDK tests pass when run against FFM.
Phase Three
Design and implement optimal FFM interface affordances for SDK APIs like Widget and Panel that modify Firefox chrome.
Phase Four
Design and implement additional API features for capabilities that are specific to mobile devices. |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Jetpack |
| Secondary roadmap | ` |
| Feature list | Jetpack |
| Project | ` |
| Engineering team | Jetpack |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=` |Feature roadmap=Jetpack |Feature secondary roadmap=` |Feature list=Jetpack |Feature project=` |Feature engineering team=Jetpack }}
Team status notes
| status | notes | |
| Products | tbd | ` |
| Engineering | tbd | ` |
| Security | tbd | ` |
| Privacy | tbd | ` |
| Localization | tbd | ` |
| Accessibility | tbd | ` |
| Quality assurance | tbd | ` |
| User experience | tbd | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=tbd
|Feature products notes=` |Feature engineering status=tbd |Feature engineering notes=` |Feature security status=tbd |Feature security health=` |Feature security notes=` |Feature privacy status=tbd |Feature privacy notes=` |Feature localization status=tbd |Feature localization notes=` |Feature accessibility status=tbd |Feature accessibility notes=` |Feature qa status=tbd |Feature qa notes=` |Feature ux status=tbd |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}