canmove, Confirmed users
1,635
edits
Features/Desktop/Add-on hotfix: Difference between revisions
Jump to navigation
Jump to search
Features/Desktop/Add-on hotfix (view source)
Revision as of 21:04, 12 October 2011
, 12 October 2011no edit summary
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{FeatureStatus | {{FeatureStatus | ||
|Feature name=Add-on | |Feature name=Add-on hotfixes | ||
|Feature stage= | |Feature stage=Feature Inbox | ||
|Feature status=In progress | |||
|Feature version=Firefox 10 | |Feature version=Firefox 10 | ||
|Feature health=At risk | |Feature health=At risk | ||
|Feature status note= | |Feature status note=Specced out, engineering work starting | ||
}} | }} | ||
{{FeatureTeam | {{FeatureTeam | ||
|Feature feature manager=Christian Legnitto | |Feature feature manager=Christian Legnitto | ||
|Feature lead engineer=Dave Townsend | |||
}} | }} | ||
{{FeaturePageBody | {{FeaturePageBody | ||
|Feature open issues and risks=* | |Feature open issues and risks=* Do we need a security review? | ||
|Feature overview=Firefox | ** Likely a superficial one | ||
* Can AMO handle the increased ping load? | |||
* Can mirrors handle the "instant" demand for an add-on across the entire user base? | |||
* Would mirrors like this more than a point release? | |||
|Feature overview=There are many issues that affect our audience after release that shouldn't require a full Firefox update. | |||
Firefox will have a hardcoded add-on id. When checking for add-on updates (every 24 hours), it will always check for a specific add-on id and install it if an update is found. | |||
|Feature users and use cases=* We ship a new feature (like http:// hiding) and the user response is extremely negative. We issue an update to the add-on that flips a pref back to old behavior | |Feature users and use cases=* We ship a new feature (like http:// hiding) and the user response is extremely negative. We issue an update to the add-on that flips a pref back to old behavior | ||
* We need to distrust a CA. We ship an update to the add-on that makes Firefox distrust it and users are silently updated within 24 hours | * We need to distrust a CA. We ship an update to the add-on that makes Firefox distrust it and users are silently updated within 24 hours | ||
| Line 19: | Line 27: | ||
* We know that Netflix/Hulu/etc does bad user sniffing for a particular Firefox version. We issue an update that drops down a infobar telling users what is happening and to contact the site, or we ship the add-on that changes the user agent on the site while they work on a fix | * We know that Netflix/Hulu/etc does bad user sniffing for a particular Firefox version. We issue an update that drops down a infobar telling users what is happening and to contact the site, or we ship the add-on that changes the user agent on the site while they work on a fix | ||
* We want to speak directly to our users with a one-time marketing message / news flash. We ship an update to the add-on that pops up an infobar with the message and then never shows again | * We want to speak directly to our users with a one-time marketing message / news flash. We ship an update to the add-on that pops up an infobar with the message and then never shows again | ||
* We want to A/B test a UI pref on beta. We ship the add-on to x% of our population or ship it to all Beta users and have the add-on enable functionality x% of the time | |||
|Feature dependencies=* Leverages existing add-on manager | |Feature dependencies=* Leverages existing add-on manager | ||
* Leverages existing add-on infrastructure | * Leverages existing add-on infrastructure | ||
* AMO would see increased traffic, need to account for that | * AMO would see increased traffic, need to account for that | ||
* Need processes around creating a stopgap update | * Need processes around creating a stopgap update | ||
|Feature requirements=* | |Feature requirements=* Firefox should look for "updates" for a particular add-on id | ||
* | * The add-on should opt-out of the '''compatible by default''' initiative | ||
* | * The add-on should never be marked "incompatible" with a firefox version, causing a UI dialog | ||
* The add-on will only do spotfixes between a particular version and the next version should make the add-on obsolete. For example, any hotfix applied to for Firefox 8 should be superseded by Firefox 9 | |||
|Feature non-goals=* Ship new features to customers via add-ons | |Feature non-goals=* Ship new features to customers via add-ons | ||
* | * Firefox core with functionality broken into add-ons | ||
* Won't replace the need for software updates | * Won't replace the need for software updates | ||
|Feature functional spec=* | * Users should be unable to uninstall hofixes | ||
* Hotfixes are shown with special UI in the add-ons manager | |||
|Feature functional spec=* Firefox should look for "updates" for a particular add-on id, w | |||
* The add-on will check AMO for updates | * The add-on will check AMO for updates | ||
* The add-on will never uninstall itself | * The add-on will never uninstall itself | ||
* The add-on id will be hardcoded | |||
* Firefox will track the last installed add-on version in a special preference. This allows the add-on to uninstall itself while preventing Firefox from reinstalling it | |||
|Feature ux design=None required | |Feature ux design=None required | ||
|Feature security review=Things to cover: | |Feature security review=Things to cover: | ||
* How to make it so malicious add-ons can't use the same hiding mechanisms | * How to make it so malicious add-ons can't use the same hiding mechanisms | ||