Firefox/AddOns/Status/current

Add-ons/e10s Program Status Report

Exec Summary/Hot Topics - Nov 1st

Since September - listed add-ons increased from ~1/10 (1600) using webextensions or marked multi process compatible to ~1/8th (2,100)

50

• 50 Beta Target populations for e10s activation (webextensions and all add-ons the authors manually marked as compatible, MPC=True) are continuing into Release.
  • 6.41% of Beta users qualified: 80,000 in test group and 80,000 in control group
  • Expect 6-10% in Release. This is an increase of 3-7% in eligible, users above those that qualified for e10s in Release 49.
  • Listed add-on counts that meet the target population criteria are at the top of arewee10syet. ~2100
  • No issues correlated to this add-on/e10s inclusion with Stability or Performance.
• SDK Performance fixes were excepted late into Beta 50 cycle - delaying 50 Release to Nov 15.
  • Anecdotal evidence showed noticeable improvements (patches landed in Nightly Oct 17 & Oct 24)
  • Testing didn't find any issues (spot tested add-ons)
  • Identifying telemetry for measuring improvements is in progress. Areas we expect to see improvements are time to first paint, fewer threadhangs, memory system compartment reduction leading to shorter GC times, potentially shutdown time
    • improvements expected in browsers without add-ons, bigger improvement in browsers with SDK add-ons, and biggest improvements across both populations when e10s is turned on.
• In 50 setting MPC=true was adjusted to also block direct CPOW usage (in addition to shims). Only a few add-ons had already used CPOWs directly, and are excluded for a brief transition period.

51

• Beta 51 is going to target going broadly with e10s to add-ons users, everyone except MPC=False or specifically excluded (due to issues found)
  • Soft Vision has done an excellent job testing to largest add-ons
  • Beta 51 will show how much the longer tail are using newer technology, not impacted by e10s, or covered by shims.
  • need to look at throttle Release availability for add-ons.
  • In 49 and 50 the qualifying number of users was what we'd want to activated at one time. Beta 51 targeting we expect more like 20-40% to qualify and we may not want to make that change at once in release.

49

• 49 release target populations did not show negative stability impact from including webextensions and 10 named add-ons (~1120 add-ons) in groups that receive e10s
  • Roughly 3% of Release population now qualifies, based on add-ons/e10s 49 criteria
  • users with add-ons not in the target group will continue to work and just not have e10s activated

Release 49 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
Experiment Definition		Targeting 8 named tested MPC:true add-ons and all webextensions based (~950)		Beta49
Beta Release Criteria		Using the RC from e10s, choosing the ones that are applicable from telemetry and stability		Beta49
Data Collection & Analysis		Beta successfully delivered to 28,000 addons\e10s Test users and 28,000 addons\no-e10s control. Beta Stability and Performance metrics in place. Released to 3.6 million users. Release stability and engagement metrics in place.		Release49
Manual Testing		Working well with SoftVision for testing any needed add-ons and system add-on itself.		Beta49
Release Management Approval		Rode trains in Beta through to Release.		Release49
Release Metrics & Criteria		Fewer metrics are available in Release. Stability and Daily Active Users are monitored.		Release49

Beta/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
Beta 50 Experiment Definition/selection		Target continues to contain MPC:webextensions - expanding to all MPC:true. Currently 6.4% of Beta population qualifies (112,000 users).		Beta50
Data Collection & Analysis		Beta successfully delivered to 28,000 addons\e10s Test users and 28,000 addons\no-e10s control. Beta Performance and Stability metrics in place.		Beta50
Manual Testing		Working well with SoftVision for testing any needed add-ons and system add-on itself. Checking how long they can support incoming add-ons for validation.		Beta50
Release Management Approval				Beta50

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.

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 1, 2016

• WebExtensions has been the most popular platform for new add-ons since July
• 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 52
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. UX is vital here as some permissions are more sensitive than others and the flow to expose the right user experience based on the circumstances is critical.	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		ETA Fx52
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
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.
Out of Process

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).	Open	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.	Open	Andym	Fx51	There really isn't a mitigation to this one. It will impact if issues trump current work.

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