Add-ons/Projects: Difference between revisions
< Add-ons
Jump to navigation
Jump to search
No edit summary |
(add h2s, begin adding AMO categories & content) |
||
| Line 3: | Line 3: | ||
== Firefox/Quantum Platform == | == Firefox/Quantum Platform == | ||
=== WebExtension APIs === | === New WebExtension APIs === | ||
These are the confirmed and prioritized APIs, with their corresponding tentative target release version in parentheses: | These are the confirmed and prioritized APIs, with their corresponding tentative target release version in parentheses: | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 21: | Line 21: | ||
| Toolbars || 63 (TBD) | | Toolbars || 63 (TBD) | ||
|- | |- | ||
| Overlays || 64 | | Overlays || 64 (TBD) | ||
|} | |} | ||
| Line 32: | Line 32: | ||
: Removing support for bootstrapped extensions continues the process that was begun when we removed support for arbitrary bootstrapped extensions (on release and beta) and allows for the removal of more unused code. The remainder of bootstrapped extensions should be converted to web extensions or achieve their aim some other way (these are primarily internal). [targeting 64] | : Removing support for bootstrapped extensions continues the process that was begun when we removed support for arbitrary bootstrapped extensions (on release and beta) and allows for the removal of more unused code. The remainder of bootstrapped extensions should be converted to web extensions or achieve their aim some other way (these are primarily internal). [targeting 64] | ||
=== | === Mission-critical technical needs === | ||
; Remove support for unpacked extensions | ; Remove support for unpacked extensions | ||
: The add-ons manager codebase currently support two separate code paths, one for unpacked and one for packed. This doubles the maintenance and testing burden, and unpacked, in particular, is prone to bugs and performance issues. It is no longer recommended on MDN. [targeting 62] | : The add-ons manager codebase currently support two separate code paths, one for unpacked and one for packed. This doubles the maintenance and testing burden, and unpacked, in particular, is prone to bugs and performance issues. It is no longer recommended on MDN. [targeting 62] | ||
| Line 69: | Line 69: | ||
; Feed desired extension that triggered install to /firstrun | ; Feed desired extension that triggered install to /firstrun | ||
: A substantial opportunity for add-on installation is to determine if a user installed Firefox from an AMO detail page. Add-ons users (whether new or pre-existing) retain at a higher rate than non-Add-ons users. [targeting 63] | : A substantial opportunity for add-on installation is to determine if a user installed Firefox from an AMO detail page. Add-ons users (whether new or pre-existing) retain at a higher rate than non-Add-ons users. [targeting 63] | ||
== addons.mozilla.org == | == addons.mozilla.org == | ||
=== Continuation of migration to Extensions === | |||
; Support Static Themes on AMO | |||
: AMO needs to support extension-based themes for developers, reviewers, and end users. This includes deprecating existing theme APIs and discontinue (XUL-based) complete themes. [targeting Q3] | |||
; Support static themes on frontend | |||
: Enable the presentation of static themes on AMO. [targeting Q3] | |||
; Theme Migration | |||
: Migrate lightweight themes to static themes. [targeting Q3] | |||
; WebExtensions Dictionaries | |||
: In order to move away from legacy packaging and legacy manifests, we should move dictionaries to WebExtensions packaging. | |||
; Dynamic Theme Classification | |||
: We need to make a distinction between two types of themes: static and dynamic. All themes should be shown under 'themes' on AMO, but we need to determine how a developer specifies that, submits it, and what precautions or limitations we should put in place to protect users as much as is reasonable and prudent. | |||
== web-ext == | |||
[https://github.com/mozilla/web-ext Web-ext] is a command-line tool to assist developers in extension development and submission. | |||
== WebExtension browser API polyfill == | |||
[https://github.com/mozilla/webextension-polyfill you are here] | |||
== Add-ons Linter == | |||
The [https://github.com/mozilla/addons-linter JavaScript-based Add-ons Linter] is used in AMO submission and web-ext to analyze developer code for errors, warnings, and constraints to ensure quality and security standards prior to submission and publication. | |||
== Marketing/Community Engagement == | == Marketing/Community Engagement == | ||
Revision as of 21:03, 31 May 2018
These are projects that are being worked on in Add-ons.
Firefox/Quantum Platform
New WebExtension APIs
These are the confirmed and prioritized APIs, with their corresponding tentative target release version in parentheses:
| API | target release |
|---|---|
| userScripts | 62 |
| topSites | 62 |
| desktopCapture (TBD) | 63 |
| declarativeContent | 62 |
| Session management | 63 (TBD) |
| Toolbars | 63 (TBD) |
| Overlays | 64 (TBD) |
- In discussion: color filter API
- Future: link to prioritized backlog (in progress)
- Future: link to long-term backlog (in progress)
Continuation of migration to Extensions
- Remove uses of bootstrapped extensions
- Removing support for bootstrapped extensions continues the process that was begun when we removed support for arbitrary bootstrapped extensions (on release and beta) and allows for the removal of more unused code. The remainder of bootstrapped extensions should be converted to web extensions or achieve their aim some other way (these are primarily internal). [targeting 64]
Mission-critical technical needs
- Remove support for unpacked extensions
- The add-ons manager codebase currently support two separate code paths, one for unpacked and one for packed. This doubles the maintenance and testing burden, and unpacked, in particular, is prone to bugs and performance issues. It is no longer recommended on MDN. [targeting 62]
- Telemetry improvements
- Telemetry of the add-ons manager (about:addons) and performance of addons is currently incomplete. [targeting 62]
Performance improvements
- Storage.local backend change to indexedDB
- Improve performance and memory usage; also part of quantum flow. [targeting 62]
Engineering improvements
- Context menu improvements
- Follow-on work for context menus and associated APIs. [targeting TBD (63 or 64)]
- Resolve browser_style issues
- The browser_style manifest key is unclear in how it relates to built-in themes, user themes, and how maintenance should extend to add-ons requirements which may or may not be present in extensions.css. [targeting TBD]
- Improve support for incognito
- There are outstanding issues with extensions, private browsing, and the incognito manifest key. [targeting 62]
- Themes resolution
- The introduction of static themes and the Theming API introduce a host of UX issues on AMO and in Firefox that depend on a more concrete definition of "themes" and constraints to the Theming API. This affects both sides of Add-ons, the Visuals team, and community. [targeting 63]
- Delayed background startup pref'd on beyond Nightly
- This fixes an issue with proxy and webRequest (at least), and results in extensions not needing to start during browser startup. [targeting 62]
UI improvements
- Tabs post-launch
- Follow-on work from the release of Tab Hiding in 61 to complete visual indications and UI. [targeting 62]
- UI for exposing how extensions change Firefox
- As part of increasing awareness of extensions, we need to show users in the Firefox UI what extensions do to their browser after they are installed. This includes, but is not limited to, showing permissions, allowing optional permission control, showing command (keyboard shortcut) combinations, notifying of collisions, and allowing the user to override key functionality (search engine, home page, new tab), and more. [ongoing]
Discoverability
- Feed desired extension that triggered install to /firstrun
- A substantial opportunity for add-on installation is to determine if a user installed Firefox from an AMO detail page. Add-ons users (whether new or pre-existing) retain at a higher rate than non-Add-ons users. [targeting 63]
addons.mozilla.org
Continuation of migration to Extensions
- Support Static Themes on AMO
- AMO needs to support extension-based themes for developers, reviewers, and end users. This includes deprecating existing theme APIs and discontinue (XUL-based) complete themes. [targeting Q3]
- Support static themes on frontend
- Enable the presentation of static themes on AMO. [targeting Q3]
- Theme Migration
- Migrate lightweight themes to static themes. [targeting Q3]
- WebExtensions Dictionaries
- In order to move away from legacy packaging and legacy manifests, we should move dictionaries to WebExtensions packaging.
- Dynamic Theme Classification
- We need to make a distinction between two types of themes: static and dynamic. All themes should be shown under 'themes' on AMO, but we need to determine how a developer specifies that, submits it, and what precautions or limitations we should put in place to protect users as much as is reasonable and prudent.
web-ext
Web-ext is a command-line tool to assist developers in extension development and submission.
WebExtension browser API polyfill
Add-ons Linter
The JavaScript-based Add-ons Linter is used in AMO submission and web-ext to analyze developer code for errors, warnings, and constraints to ensure quality and security standards prior to submission and publication.