Firefox/Features/Expose Add-on Performance
|Expose add-on impact information at AMO and in Firefox|
|Product manager||Justin Scott & Asa Dotzler|
|Directly Responsible Individual||Justin Scott|
|Lead engineer||Hernan Rodriguez Colmeiro, Dave Dash, Justin Dolske|
|Privacy lead||Sid Stamm|
|QA lead||Henrik Skupin|
|UX lead||Jennifer Boriss|
|Product marketing lead||`|
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.
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.
Stage 2: Design
5. Functional specification
6. User experience design
- Early design mockup: shows percentage of runtime used for each addon.
- : newer mockup of the first stage
Stage 3: Planning
7. Implementation plan
Quality Assurance review
Stage 4: Development
File AMO bug to expose performance information in the API
- File AMO bug to make use of the new fields and display warnings when appropriate.
File Firefox Add-ons Manager bug to make use of the new fields and display warnings when appropriate.
- Obtain designs for the Add-ons Manager
- Implement the designs in the Add-ons Manager.
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
|Engineering team||Desktop front-end|
Team status notes
|Products||`||For more information, please see   |
|Security||sec-review-complete||complete: 10.05 Notes|