Firefox/AddOns/Status/current

Add-ons/e10s Program Status Report

Exec Summary/Hot Topics - Feb 14th

53

• The goal in 53 is to allow e10s to expand to all users, unless they have add-ons marked specifically MPC=False (not multiprocess compatible)

52

• Beta has the same criteria as 51. Ensuring that the targeting add-on accurately keeps e10s from users with add-ons marked MPC=False

51

• Release 51 expanded to several hundred add-ons that were not marked (either MPC=True or MPC=False). These add-ons were in Beta and did not cause issues with Firefox performance or stability (functionality could not be tested, but if reported the add-ons were removed from sample). These are in addition Release 50 criteria of MPC=True and webextensions.
• Beta 51 expanded e10s to all users with add-ons unless they are specifically marked MPC=False or specifically excluded (due to issues found)
  • In 49 and 50 the qualification criteria limited the number of users activated at once.
  • Beta 51 Release expansion would be more users than we want to activate at once. If the Beta goes well, Release expansion criteria will be Release 50 requirements (MPC=True and webextensions) and a list of all add-ons that hit a threshold of use in Beta 51 (threshold TBD).
  • Beta Goal: See if "shims" impacts performance/stability significantly in Beta.
  • The first 5 Betas will be a Baseline - using the same criteria as Release 50
  • The expanded addons-e10s experiment will be turned on in Beta 6 (~Dec 10) until Jan 13th
  • We need the Baseline to correlate issues to specific add-ons if needed, using direct profile comparison.
• Release stability metrics continue to have no significant difference between stability for e10s without add-ons and e10s with add-ons.
  • SDK Performance fixes were excepted late into Beta 50 cycle - delaying 50 Release to Nov 15, 2016. Anecdotal evidence showed noticeable improvements (patches landed in Nightly Oct 17 & Oct 24) and telemetry showed fewer hangs and shorter duration.

Release 51 Details

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Action	Status	Description	Meta Bug	Target
Add-on/e10s Criteria		Webextension add-ons and those marked MPC=True continue to get e10s. Additionally expanded e10s to 770 add-ons that were not marked (either MPC=True or MPC=False). The add-ons were selected based on having over 50 beta users, that did not show impact to performance or stability. This is an intermediary step for throttle-ing the numbers of users added to e10s in one release.

Release 50 Details

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Action	Status	Description	Meta Bug	Target
50 Experiment Definition/selection		Target continues to contain MPC:webextensions and all MPC:true. Was 6.4% of Beta population qualifies (112,000 users) - estimated at 6-10% of Release.		50

Projects to ease the transition

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Action	Status	Description	Meta Bug	Target
Testing Criteria Defined		Worked with SoftVision (michelle) on what information was needed from addon/e10s testing to make actionable decisions		Aug 1
Predict which add-ons won't work		Looking to see if there are criteria we can use to predict which add-ons will not work (of those not manually marked compatible or not). This will be used in Beta 51	bug 1281284	Late October
Throttling target audiences		Beyond 50, we'll need a way to throttle availability to Release as we expand the eligible target groups.	Plan/schedule work in October
Add-on Compatibility Reporter		The Add-on Compatibility Reporter will add in capability for END-USER reported e10s add-on compatibility (and visibility into the MPC flag setting). End-user will be able to report if it is working for their platform or also if it is not. Developers will have visibility into the e10s status (manual testing - not automated) and reported issues. Get the new version.
Communications		Continuing direct contact via email to impacted groups.
Participation Team Collaboration		Brian King facilitated community Activate campaigns to test featured content for e10s compatibility (incompatible add-ons will be removed from the featured collection by Fx50).		Nov. 11

Risks & Issues

Description of Risk/Issue	State	Owner	Version	Plan to Resolve/Mitigation	Target Date
Other platform changes around e10s (sandboxing, multi-tab, c-types, etc.) coming down the road. Factoring in the impact and timing for communications.	Open	Shell	Release 51-54	Doing everything possible to mitigate the obvious risks and work with partner teams on timing / add-on impact. Working with other teams on areas impacted and getting documented. Increasing telemetry in Beta and Nightly - expanding to include hang and hang duration (already covering all release criteria). Experiment in Beta 51 to try and identify specific add-ons that experience problems so was can pro-actively share out (crash, SUMO, telemetry, bugs).

Schedule

The following schedule covers steps in the transition to webextensions by November. There is a blog post with the detailed plan, this is the visual.

Date	Nightly	Aurora	Beta	Release	Target %	Submission Criteria
2017-01-24	Fx 54: Sandboxing and multi content processes [A]	53 default	Fx 52: All but MPC=False	Fx 51: everything from Fx50 and ~750 add-ons not marked MPC=True [B].	22
2017-03-07	Fx 55	Fx 54: Sandboxing and multi content processes [A]. Multiprocess won't ride to Release.	Fx 53: All but MPC=False [B]	Fx 52: same as 51	22
2017-04-18	Fx 56	55 default	Fx 54: Sandboxing and multi content processes [A].	Fx 53: All but MPC=False get e10s [B]	34	Submissions: Stop accepting new Legacy [D] add-ons (still accepting Legacy updates). New Webextensions only.
2017-06-12	Fx 57: Supporting only Webextension. Removing compatibility shims [E]. Stop running Legacy add-ons [D][C]	56 default	55 default	Fx 54: Sandboxing [A]	*
2017-08-07	Fx 58	Fx 57: Supporting only Webextension. Removing compatibility shims [E]. Stop running Legacy add-ons [D][C]	Fx 56	Fx 55: Multi content processes, potentially throttled roll-out [A].	*
2017-10-02	Fx 59	58 default	Fx 57: Supporting only Webextension. Removing compatibility shims [E]. Stop running Legacy add-ons [D][C]	56	*
2017-11-15	Fx 60	59 default	58 default	Fx 57: Supporting only Webextension. Removing compatibility shims [E]. Stop running Legacy add-ons [D][C]	38	Submissions: Only webextensions and updatese to webextensions for Firefox Release channel.

• [A] Sandboxing and Multicontent processes details
• [B] detailed write up on roll-out and Beta plans
• [C] High level view of the next few months changes
• [D] Definition of legacy (all non-webextensions)
• [E] Compatibility shims explanation

Sandboxing

Content security sandboxing in Firefox is a security measure that restricts operating system access malicious content can gain through security vulnerabilities. Add-ons which interact with the file system through content scripts will be impacted by this feature. Currently file system write restrictions are rolling out on various platforms in Firefox 50 and Firefox 52. File system read restrictions will start rolling out in Firefox 54. Add-on authors should familiarize themselves with areas of the file system that will be blocked by these features as they roll out, and adjust their Add-on code to avoid any potential issues.

This wiki has the exact details of how security.sandbox.content.level affects file access. We don’t expect add-on issues with sandboxing level “1” (write access). This has already begun rolling out in Firefox 50. It required e10s, or sandboxing will not be applied.

The sandboxing capability that could impact certain add-ons is read access, which starts riding the trains in Firefox 54. It will be implemented by OS. You can find the planned releases for OS and sandboxing level here.

There is a preference you can use to see if content sandboxing is enabled. In about:config, a Security.sandbox.content.level of “0” means that sandboxing is not enabled. Levels “1” or “2” control the level of content sandboxing. To troubleshoot if your add-on is experiencing issues with sandboxing (and what level of sandboxing), you can reset the number to “1” and/or “0” to see if the issue goes away.

Multiplecontent Processes

A multiple content processes model (e10s-multi) is starting to roll out in Nightly 55. It required e10s, or multi content processes will not be applied. It is not expected to go to release until mid-2017 and for the most part should not impact add-ons.

Possible add-ons that could be impacted:

• With multi-content processes, JSM has to be loaded for every process. If JSM is loaded only once and expected to run globally, the add-on may break. Process script is the suggested way for observer registration instead of JSMs.
• SDK based add-ons can come with a big memory overhead per process. If the SDK loader (especially node.js) is slow, it will be slow multiple times now in each process.
• If the add-on assumes that they only have one content process, it could falsely expect that observer and category registration to run only once. Instead it will run once per content process. If the add-on then uses it for something else (ex: to try sending some important message to the parent side that the content side is active) the parent may get multiple messages and some of the messages may arrive before other content processes are ready.

There is a preference you can check to see if multiple content processes are enabled. In about:config, a dom.ipc.processCount of 1 means that multiple content processes are not enabled. Any number higher than 1 and the browser is using multiple processes. To troubleshoot if your add-on is experiencing issues from multiple content processes, you can reset the number to 1 to see if the issue goes away.

Add-ons WebExtensions Status Report

Here is the current list of how WebExtensions correlate to the JetPack SDK and links to documentation. The idea is if something is developed for Chrome it will take no to minimal effort to move to Firefox. Microsoft Edge and Safari are also adopting this model. WebExtensions are being built multi-process (e10s) compliant. Whenever possible we are focusing on creating WebExtensions APIs first that also assist the most Firefox add-ons with upgrading to multi-process compatibility.

Exec Summary/Hot Topics - Nov 30, 2016

• WebExtensions has been the most popular platform for new add-ons since July
• Add-on plans for 2017 blog. There will be many more going into the details for different scenarios.
• Communication coming end of November for 2017 plans and updates around add-on development platform
• Adoption:
  • Listed WebExtensions - July=779: Sept=1,007: Oct=1,146.
  • Unlisted WebExtensions - July=7,848: Sept=11,692: Oct=13,371
  • ADI for the listed add-ons increased from July=604,782: Sept=2,798,403: Oct=2,923,639
  • arewee10syet.com shows "compatibility" based on being a WebExtension or the author manually marking add-on as compatible.

Focused WebExtensions APIs

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Feature Name	Top Line Initiative	Meta Bug	Health	Status
Web Experiments	What: An area for developers to develop and experiment with APIs. These experimental APIs are in an add-on outside of Firefox. Goal: Move faster than the Firefox train and allow developers to be able to quickly develop and experiment with APIs, in order to provide more APIs than ever before to our users. Those APIs would land as an add-on. As APIs become stable and supported they could be moved down into mozilla-central and move from "experimental" to "stable". More details on how to use. Landed. Add webrtcUI WebExtension calls experiment in progress.	bug 1263011		Fx 51
runtime.connectNative	Allows you to connect from a Firefox add-on to a native process. Might be relevant to you if you use NPAPI (aimed to be removed in Firefox 52). More details on how to use.	bug 1190682. Landed		Fx 50
Gap Compat for top 30	Let's enable the running of WebExtensions add-ons built for Chrome with zero (or minimal) modification in Firefox. There are several areas beyond API compatibility that are being addressed (validation, ID, format, etc.). More details are here.	bug 1161828
Management API	Used by many of the top add-ons, this is a priority API.	bug 1282979		Fx 51
Proxy API	As this API differs from what is available in Chrome, a design spec has been reviewed and implementation started	bug 1283639		Fx 54
DevTools API	Key improvements to add-on debugging. There are at least 3-4 big developer add-ons that are used by many developers and schools that we not well supported on Firefox. Aiming for for those in time for 51 (in developer edition).	bug 1211859		Fx51 and Fx52
Permissions	Some Chrome APIs have the concept of notifying/getting permission from users when certain access is required. In the Firefox webextension implementation - we need to provide that notification capability. More importantly that trying to copy Chrome is that it gives power and visibility to a user about what an add-on is doing. In legacy Firefox add-ons there really is no way to tell what an add-on does. This improves communication, empowerment and all that stuff we care about for the users. Starting with Install permissions and expanding to Upgrade and Update.	bug 1197420		53 & 54
WebRequest API	Needed by Ghostery, Flashgot, and is being worked on by Giorgio - who will be updating Ghostery. Mixedpuppy is patching some bugs	bug 1213483		Fx51
chrome.storage.sync API	An add-on developer can save some data related to the add-on and it is accessible to the same add-on for that user on different profiles and devices. There are two components to this API: the API in Firefox and the backend storage servers. For more details, wiki	bug 1220494		Fx53
Hybrid API	Provide a simple transition path to help an add-on which was initially created using the other available add-on technologies to make use of the WebExtension API. At the same time it helps being gradually rewritten into a WebExtension addon (at least as much as the available APIs permit to).	bug 1252227		Fx 51
OmniBox API	Allows you to register a keyword with Google Chrome's address bar, which is also known as the omnibox.	bug 1166831		Fx 52
Themeing API as webextension	In scope: look and feel of firefox: lightweight themes, compact, accessibility, colors, tab styles, positions, iconography	bug 1166831		Fx 54
Out of Process	Besides setting the remote=true attribute on the browser elements used for extensions, we'll need to move the API-injected code to the other process (via content scripts or something). We'll also need platform support to ensure that all the <browser> elements for a given add-on run in the same process.	bug 1190679		Fx53
Comms	Establish and document process for WebExtensions APIs decisions and communicate broadly. Triage criteria for "design-decision-approved" APIs to encourage community contributions. One-on-one outreach to top 20-30 add-ons to help them migrate to WebExtensions.

Risks & Issues

Description of Risk/Issue	State	Owner	Version	Plan to Resolve/Mitigation	Target Date
After releasing many new API's in Fx48, we are finding and fixing bugs - which has slowed down some of our initial goals (some that we had hoped to land in Fx50 are more Fx51).	Closed	Andym	Fx51	Now targeting the Aurora version of 51 for a milestone release. Extra testing. Early triage and fixing of bugs by the team.	Sept 12
Focus on e10s impacting work may make us prioritize some complex APIs used by a few widely adopted add-ons, rather than addressing some of the broader adoption and simpler APIs as quickly as we want. Currently at risk is Permissions.	closed	andy	Fx51-54	Permissions moved out 2 releases. only enabling SDK tests that work - disabling rather than fixing others. Months of work to fix SDK tests in Try would have traded off for DevTools (not good bargain over next few months). Implementing more metrics in Beta (for hangs) and continuing to monitor. Several high impact fixes to SDK in performance that reduced hangs and hang length significantly.

Addons.mozilla.org Status Report

AMO has grown to be complex, to the point where touching parts of its code is bound to trigger new bugs and edge cases. Most of this complexity stems from the review process and the multiple different states add-on and add-on files can have. The introduction of unlisted add-on reviews has exacerbated this problem. We need to find ways to simplify AMO, so it is easier to work with in the longer term.

One of our primary goals as a team is to increase the use of add-ons (the other is to increase the development of add-ons). Users who self-install add-ons tend to use the product more, and we want to give users every opportunity to discover and use add-ons that are useful, safe, and affect the user experience positively.

Everything we do with addons.mozilla.org should feed into this goal, and we should have an idea of how the changes we make to AMO forwards these goals, and how we measure the success of those changes.

Exec Summary/Hot Topics - Aug 8th, 2016

• In Firefox 48 the improved Discovery Pane experience will be present. This greatly simplifies the download and install of new add-ons. It is the first stage of making add-ons more accessible to a broader group of people.
  • The blog post Discovery Pane Editorial Policy covers why the add-ons exposed are limited.
  • Plans for content include keeping it fresh and also making the transition from Discovery Pane to full world of add-ons a better integrated experience (consistency and intuitiveness)
• User Research on the Discovery Pane showed a major win with the toggle install (very intuitive). We also learned several areas that are not intuitive (language between add-ons/extensions, uninstall/managing, search, consistency with AMO pages, initial amount of detail available).
  • We have work planned on Search & Consistency. We are evaluating other feedback for highest impact.
• A near future once the Discovery Page design is sorted out will be to expose in other locations (UI Tour, Initial install, etc.)

Q3 Goals

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Feature Description	Top Line Initiative	Meta Bug	Health	QA Status	Status
Mobile Pages	Moving mobile views to the new React front end to roll out the new AMO front-end using new functionality for easier refactoring. We are doing mobile first because (1)limited use- breaking things has less impact and let's us scale (2)limited scope- three are only a few pages, and (3)limited features. We can then make it responsive and scale up to the desktop. For more details, see theMobile Pages wiki.
Quicker, easier, less risky change	Get AMO onto a cycle where all the requirements are up to date and able to be updated quickly and easily. Some key goals would be: get us on newest Django 1.8, remove schematic, and aim us for Python 3 in 2017. There will be huge technical debt wins in addons-server when we move large amounts of code out to React and the new front-end so we need to be careful about what we try to remove.
Replace Search Page	The current Search page in the Add-ons Manager has a lot of accumulated technical debt, which makes updates spawn more bugs than it solves. Will update the entire page to the new look and leverage the Search APIs for greatly improved add-on search capability.
UX for main web pages	While implementing the Mobile Pages, take what we learn and address the more complex desktop Firefox AMO pages. This will include resolving several AMO questions about how to better handle actions.
Disco pane content	Establish a process and monthly cadence for refreshing disco pane content

Risks & Issues

Description of Risk/Issue	State	Owner	Version	Plan to Resolve/Mitigation	Target Date
Risk description	Open	Owner	Version	Mitigation	ETA

Add-on Developer Experience Status Report

Another of our primary goals as a team is to increase the development of add-ons (the other is to increase the use of add-ons). We need to attract and enable developers to create and distribute add-ons so users can discover and use them.

Everything we do with add-on technologies, addons.mozilla.org, and communities should feed into this goal, and we should have an idea of how our priorities forward these goals, and how we measure their success.

Exec Summary/Hot Topics

• Preliminary review step removed
• Publish detailed review quality policy (Enforcement)
• Hiring more reviewers

H2

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Feature Description	Top Line Initiative	Meta Bug	Health	Status
Developer Communications	Improve both directly inside the Submission/Review process (with feedback) as well as accurately, timely, targeted outreach (salesforce, contact tools).
Developer Hub	Update landing page on AMO to be a one-stop resource for developers. Can link off to other areas like blogs and MDN, but everything should be discoverable on the landing.
Submission Flow
Channels	Support listed & unlisted channels to allow easy switching - No owner committed to dev project yet
Queues Experience
Remove Preliminary Review Step	Problem: the preliminary review status & sideloading flag make the review process more complex than just approve/reject. Proposed solution: eliminate preliminary review & sideloading cert distinction. The work for removing preliminary review is almost all in place. Expect these changes to go live before the end of August.	Issue 3083

Risks & Issues

Description of Risk/Issue	State	Owner	Version	Plan to Resolve/Mitigation	Target Date
Issue	Open	Owner	Version	Remediation	ETA

Volunteer Community Status

Volunteer contributors dedicate their time and energy to support our efforts in providing personalization and choice to people on the web. Many are also creators or consumers of content (like developers and users), but volunteers go a step beyond, keeping the add-on ecosystem running by contributing to functional areas like coding, reviewing, translations, evangelism, support, and community mobilization.

The goal is to ensure a healthy contributor funnel, moving people up the contribution curve from awareness to membership, belonging to leadership. A contributor should be able to discover the ways they can make an impact, onboard, receive support and mentorship, and be empowered to participate and lead.

Exec Summary/Hot Topics

• Improve code contributor experience and recognition tracking:
  • Revamp Code Contribution Page
  • Update contributing.rst on GH
  • Create bot to send an email to community team every time a contributor gets a patch merged on GH
  • Begin recognizing contributors in every AMO update blog post
• Develop review quality process and tracking, publish and communicate to reviewers

H2

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Feature Description	Top Line Initiative	Meta Bug	Health	Status
Code Contribution program	Improve code contributor experience and recognition tracking
Community Coordinator hire
Contributors in Hawaii
Add reviewer levels to SalesForce	Import level and prize history for better incentive program support
Sync with participation team	Coordinate /contribute and onramp pages

Risks & Issues

Description of Risk/Issue	State	Owner	Version	Plan to Resolve/Mitigation	Target Date
Issue	Open	Owner	Version	Remediation	ETA

Current Program/Project Work - August 9th, 2016

We have a cross-team meeting where the managers get together to make sure we are aligned, discuss what's coming up, and what is needed in near future.

Exec Summary/Hot Topics

• New Trello board to track projects and who has the "to do" to move it along.
• Discussing the naming of webextensions and if we want a Browser mention.
• Revamped code contribution page

Details

On track, issues well managed Some risks, unknowns without clear mitigations Blocked on deliverables, needs decision, escalation required

Action	Status	Description	Meta Bug	Impacts

Risks & Issues

Description of Risk/Issue	State	Owner	Version	Plan to Resolve/Mitigation	Target Date
Lorem ipsum dolor sit amet consetetur sadipscing elitr sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat sed diam voluptua	Open	Joey	VX.Y	At vero eos et accusam et justo duo dolores et ea rebum Stet clita kasd gubergren no sea takimata sanctus est Lorem ipsum dolor sit amet	February 30th

H1 2016 Progress

Webextensions Milestone 48

WebExtensions have been present since Firefox 42. With the release of Firefox 48, we feel WebExtensions are in a stable state. We recommend developers start to use the WebExtensions API for their add-on development.

The initial set of WebExtension APIs included in this release are: compatible with their counterparts in Chrome and Opera, fully compliant with Multi-process Firefox (aka “Electrolysis”, or “e10s”), and better sandboxed so it’s easier to assess your add-on’s safety.

Many APIs gained improved support in this release, including: alarms, bookmarks, downloads, notifications, webNavigation, webRequest, windows and tabs. We are continuing to add additional API support in future releases.

If you have authored an add-on in the past and are curious how it’s affected by the upcoming changes, please use the lookup tool. There is also a wiki page filled with resources to support you through the changes.

Other changes:

• validator support for submitted webextensions bug 1210037
• Implemented contextMenus API for open extension bug 1190667
• Prioritized API's for upcoming work (may be done - check the bug link for status)
  • Port key add-ons to Web Extensions (ex: No Script, Pentadctyl, tree tab plus)
  • Implement history API for open extension API bug 1208334
  • Implement sidebar extension point bug 1208596

Improve Add-ons Discovery and Management

We are in the process of rewriting AMO. The first part was the Discovery pane, which is a page provided by AMO and embedded inside Firefox. This has landed in Fx48.

Add-on Signing

The release of Firefox 48 marks the final deployment of mandatory extension signing, after years of work. There's still some follow up work to be done, but we're finally in a place where release versions of Firefox are better protected against malicious add-ons.

With Firefox 48, extension signing can no longer be disabled in the release and beta channel builds by using a preference. As outlined when extension signing was announced, we are publishing specialized builds that support this preference so developers can continue to test against the code that beta and release builds are generated from. These builds do not use Firefox branding, do not update automatically, and are available for the en-US locale only.

We’ll be maintaining links to the latest beta and release builds on the Extension Signing page on the Mozilla Wiki as they come out. Additional information on Extension Signing, including a Frequently Asked Questions section, is also available on this page.

Blog posts:

• Add-on Signing Update - toggling preference delayed to 46
• Signing Firefox add-ons with jpm sign
• Signing API now available

Reducing the Review Queue

Full blog here. As you can see, we were doing pretty poorly on review turn-around in late 2015. We only had one admin reviewer, Andreas Wagner, whose attention was almost entirely focused on reviewing unlisted add-ons (not included in the charts). We already had a significant backlog of add-ons awaiting admin review, and during this time it got a lot worse. We were looking for new admin reviewers we could get on board as contractors, but most of our attention was focused on extension signing.

The green area represents add-ons that have been waiting under 5 days, yellow between 5 and 10 days, and red over 10 days. Starting in H1, the review queues are now almost entirely in the green, which is fantastic.

alt text

alt text

A few things happened that helped us get the review queues under control:

• We stopped gating unlisted add-on signing by review. This freed Andreas’s time so he could go back to review listed add-ons.
• Our team grew. We now have Philipp Kewisch as our second full time admin reviewer and Noitidart helping part time also as an admin. Other areas of the team also got help, like the AMO dev team and editorial, all of which has afforded us much-needed breathing room and focus.
• Our volunteer team also ramped up their efforts and kept up with the increased submission rate. During the first few weeks of the year, they averaged over 500 reviews per week! This is an amazing feat, especially to those of us who know about the pains of code review.

Important Links/References

• How to contribute to this project
• Trello board for Add-on Planning