Firefox/Features/Expose Add-on Performance

From MozillaWiki
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Status

Expose add-on impact information at AMO and in Firefox
Stage Definition
Status In progress
Release target `
Health OK
Status note `

{{#set:Feature name=Expose add-on impact information at AMO and in Firefox

|Feature stage=Definition |Feature status=In progress |Feature version=` |Feature health=OK |Feature status note=` }}

Team

Product manager Justin Scott & Asa Dotzler
Directly Responsible Individual Justin Scott
Lead engineer Hernan Rodriguez Colmeiro, Dave Dash, Justin Dolske
Security lead `
Privacy lead Sid Stamm
Localization lead `
Accessibility lead `
QA lead Henrik Skupin
UX lead Jennifer Boriss
Product marketing lead `
Operations lead `
Additional members `

{{#set:Feature product manager=Justin Scott & Asa Dotzler

|Feature feature manager=Justin Scott |Feature lead engineer=Hernan Rodriguez Colmeiro, Dave Dash, Justin Dolske |Feature security lead=` |Feature privacy lead=Sid Stamm |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=Henrik Skupin |Feature ux lead=Jennifer Boriss |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}

Open issues/risks

`

Stage 1: Definition

1. Feature overview

Users should be informed when an add-on they are about to install or have installed causes Firefox performance and or memory problems. This information should be presented at AMO and in the Firefox Add-ons Manager.

2. Users & use cases

We should develop a new Add-ons policy, and acompanying AMO and Firefox technology, which says that we will inform our add-on users and prospective add-on users about specific add-ons that can be proved to have a significant and excessive impact on memory usage and/or performance. I propose we test for start-up performance impact, page load performance impact, start-up memory use impact, and memory leaks.

The policy should specify that we will notify the authors of add-ons as soon as we discover a problem and it should have a grace period for correcting any excessive memory or performance impact. I propose, as a straw-man, half a release cycle or 3 weeks from notification.

If after the grace period the add-on is not brought within compliance, we should add it to a list of ill-behaving add-ons. That list would be consumed by both AMO and the Firefox client. Both apps would use the list to display warnings to users about the impact of the add-on.

If after an additional 3 weeks of the add-on being flagged publicly, (again, a straw man) it is not corrected, we should escalate the content of and the and visibility of the warning message.

At AMO, I believe these poorly-performing add-ons should be flagged at the add-on install page. The warning should be firm but friendly -- something like "Mozilla testing has determined that this add-on may cause Firefox performance problems". If, after some period if time from the public warning the add-on is not corrected, the message should be escalated to display in search results and with a text that would more seriously deter users, something like "This add-on is known to cause serious Firefox issues. Use at your own Risk".

In the Firefox client, the flagged add-ons should display warning text in the Add-ons Manager (where informed users, or users following the instructions of a support article or other help, would see it,) and for the escalation period, to an infobar.

This would give add-on authors 3 weeks to fix problems before potential users and some of the installed base are notified, and another 3 weeks before most potential and all existing users would see the more dire warning.

3. Dependencies

Add-on testing capabilities, manual or automated.

An AMO API for "warned add-ons" and for "doubly warned add-ons"

AMO and Firefox code to access this API, get the lists, and display UI based on the lists.

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

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

  1. File AMO bug to expose performance information in the API
  2. File AMO bug to make use of the new fields and display warnings when appropriate.
  3. File Firefox Add-ons Manager bug to make use of the new fields and display warnings when appropriate.
  4. Obtain designs for the Add-ons Manager
  5. Implement the designs in the Add-ons Manager.

Stage 5: Release

10. Landing criteria

` {{#set:Feature open issues and risks=` |Feature overview=Users should be informed when an add-on they are about to install or have installed causes Firefox performance and or memory problems. This information should be presented at AMO and in the Firefox Add-ons Manager. |Feature users and use cases=We should develop a new Add-ons policy, and acompanying AMO and Firefox technology, which says that we will inform our add-on users and prospective add-on users about specific add-ons that can be proved to have a significant and excessive impact on memory usage and/or performance. I propose we test for start-up performance impact, page load performance impact, start-up memory use impact, and memory leaks.

The policy should specify that we will notify the authors of add-ons as soon as we discover a problem and it should have a grace period for correcting any excessive memory or performance impact. I propose, as a straw-man, half a release cycle or 3 weeks from notification.

If after the grace period the add-on is not brought within compliance, we should add it to a list of ill-behaving add-ons. That list would be consumed by both AMO and the Firefox client. Both apps would use the list to display warnings to users about the impact of the add-on.

If after an additional 3 weeks of the add-on being flagged publicly, (again, a straw man) it is not corrected, we should escalate the content of and the and visibility of the warning message.

At AMO, I believe these poorly-performing add-ons should be flagged at the add-on install page. The warning should be firm but friendly -- something like "Mozilla testing has determined that this add-on may cause Firefox performance problems". If, after some period if time from the public warning the add-on is not corrected, the message should be escalated to display in search results and with a text that would more seriously deter users, something like "This add-on is known to cause serious Firefox issues. Use at your own Risk".

In the Firefox client, the flagged add-ons should display warning text in the Add-ons Manager (where informed users, or users following the instructions of a support article or other help, would see it,) and for the escalation period, to an infobar.

This would give add-on authors 3 weeks to fix problems before potential users and some of the installed base are notified, and another 3 weeks before most potential and all existing users would see the more dire warning. |Feature dependencies=Add-on testing capabilities, manual or automated.

An AMO API for "warned add-ons" and for "doubly warned add-ons"

AMO and Firefox code to access this API, get the lists, and display UI based on the lists. |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=* Early design mockup: shows percentage of runtime used for each addon.

  • [2]: newer mockup of the first stage

|Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=# File AMO bug to expose performance information in the API

  1. File AMO bug to make use of the new fields and display warnings when appropriate.
  2. File Firefox Add-ons Manager bug to make use of the new fields and display warnings when appropriate.
  3. Obtain designs for the Add-ons Manager
  4. Implement the designs in the Add-ons Manager.

|Feature landing criteria=` }}

Feature details

Priority P3
Rank 999
Theme / Goal `
Roadmap Add-ons
Secondary roadmap `
Feature list Desktop
Project `
Engineering team Desktop front-end

{{#set:Feature priority=P3

|Feature rank=999 |Feature theme=` |Feature roadmap=Add-ons |Feature secondary roadmap=` |Feature list=Desktop |Feature project=` |Feature engineering team=Desktop front-end }}

Team status notes

  status notes
Products ` For more information, please see [3] [4] [5]
Engineering ` `
Security sec-review-complete complete: 10.05 Notes
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance waiting `
User experience ` `
Product marketing ` `
Operations ` `

{{#set:Feature products status=`

|Feature products notes=For more information, please see [6] [7] [8] |Feature engineering status=` |Feature engineering notes=` |Feature security status=sec-review-complete |Feature security health=OK |Feature security notes=complete: 10.05 Notes |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=waiting |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}


Retrieved from "https://wiki.allizom.org/index.php?title=Firefox/Features/Expose_Add-on_Performance&oldid=390738"