Firefox/AddOns/Status/current

Add-ons/e10s Program Status Report

Exec Summary/Hot Topics - August 26th

• Next focus is to move ahead with finalizing inclusion of add-ons/e10s "experiment" in Release 49
  • Estimation of Release population that would qualify (based off the 2.48% of Beta that met criteria) is 5-7 million new users qualifying for e10s in Release.
  • There would be no throttling capabilities in 49 - since shared target system add-on uses same throttling as e10s.
  • First few weeks of Beta have shown no issues created by the add-on/e10s inclusion with Stability or Performance.
• After talking with Billm - he showed us how a few (5 according to telemetry) add-ons are calling CPOWs directly. This hadn't been expected. Assumed developers would use the Shims, so MPC:true doesn't block calling CPOWs.
  • Allow the 5 existing so they don't break immediately. Outreach to correct.
  • change MPC:true to also block CPOW usage (in addition to shims)
  • Evaluating if we need to update documentation
• Release Plan for add-ons/e10s, with the end goal to have e10s available for all add-on users. This is a phased plan, based on achieving a quality bar before moving onto the next phase.

Beta/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 (~500)		Beta49
Beta System Add-on		Felipe adapted the targeting add-on from original e10s experiment to target add-on/e10s testing.		Beta49
Beta Release Criteria		Using the RC from e10s, choosing the ones that are applicable from telemetry and stability		Beta49
Beta Data Collection & Analysis		Beta successfully delivered to 28,000 addons\e10s Test users and 28,000 addons\no-e10s control. Data collection and analysis adaption completed for experiment.		Beta49
Manual Testing		Working well with SoftVision for testing any needed add-ons and system add-on itself.		Beta49
Release Management Approval		Uplifted into Aurora and will ride train into Beta, through beta 6.		Beta49
Metrics Results		Stability and Performance show no issues in first 4 Betas		Beta 49
Release System Add-on		Telemetry to validate the system add-on is performing correctly. Working with Felipe to[https://bugzilla.mozilla.org/show_bug.cgi?id=1297753 adapt System add-on for Release		Release 49
Release Metrics & Criteria		Telemetry to Available Release metrics are different than in Beta - make sure we can collect them		Release 49

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 should work		After the beta experiment data (or in parallel), will work with David Zeber. The data can identify top add-ons that should be e10s compatible. We'd then test the most used ones and ask the authors to mark the add-on MPC=true. Having a good set of MPC=true add-ons will be vital for the next beta and greatly improve our potential target audience.	bug 1281284	Late August
Decisions based on results		Determine next experiment timing, target, and when to start initial GA testing (even to small segments) based on metrics results.	bug 1281274	Aug 25 for 2nd Beta and 1st GA plan.
arewee10syet website		Page has been migrated to new management (Andym), need to update criteria for States, and wording on how to test to give the best feedback.
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		Contacted 8 in experiment, need to prep for potentially going to small Release. Blog going out for developers explaining that it's not blocked.
Identifying add-ons that will "just work"		Looking at anything that can give us actionable information to share with developers. Ex: if an add-on has no CPOW's, are they default e10s compatible? If yes we can pull a report and email those authors on what it would take for them to mark MPC:true. Another options is getting author permission for us to change that flag (must check with legal on how to request this due to licensing).
Participation Team Collaboration		Brian King reached out to plan an "activity" with add-ons, which will have a shelf life of a few weeks. These activities will provide clear ways that internal or existing contributors can help with Mozilla projects. The first will be focused around a list of add-ons whose testing would most impact developers and users.

Risks & Issues

Description of Risk/Issue	State	Owner	Version	Plan to Resolve/Mitigation	Target Date
Anything going wrong in experiment, bad data, data telling us there are issues.	Open	Shell / Kev	Beta 49	Doing everything possible to mitigate the obvious risks. Will know more after first 3 betas.	Aug 25

Add-ons Webextensions Status Report

Here is the current list of how webextenstions 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 working to adopt 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 - August 26th, 2016

• arewee10syet.com is accurate as possible for "compatibility". Continue to work on data quality / outreach
  • • There are 779 listed WebExtensions and 7,848 unlisted. The listed ones add up to 604,782 ADI.
• Continuing to make progress towards a set of tools and APIs for webextensions before Firefox 51 goes into Beta (November 11) - that will enable a large amount of add-ons to move directly to webextensions.
  • Web experiments ready to speed the creation of new webextension API's. Presentation coming.
  • DevTools API will make add-on development faster. Should be completed for Fx51 Aurora
    • If you press the debug button on a WebExtensions add-on - you get a full features toolbox window. It correctly handles add-on reloads. Any issues please needinfo :rpl
  • Hybrid add-on landing in 51 Aurora (not 50)
• e10s work for SDK is creeping into slow down webextensions work.
  • The WebExtensions promo (originally scheduled to go live with 49) is being delayed until more APIs are available to developers. Instead, an email blast is going out to authors with add-ons not marked mpc=true reminding them to test and update.

Milestone 51

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.	bug 1263011		Initial API landed in Fx50
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		Fx50
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		TBD
Proxy API	As this API differs from what is available in Chrome, a design spec has been reviewed and implementation started	bug 1283639
DevTools API	There are some key improvements we can make 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
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		TBD
WebRequest API	Needed by Ghostery, Flashgot, and is being worked on by Giorgio - who will be updating Ghostery.	bug 1213483		ETA 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 Fx51
Hybrid API
Comms	Launch promotion to engage developer community on WebExtensions and e10s compatibility
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