Features/Desktop/Add-on hotfix: Difference between revisions

Features/Desktop/Add-on hotfix (view source)

Revision as of 23:50, 28 October 2011

2,992 bytes added , 28 October 2011

no edit summary

Clegnitto

canmove, Confirmed users

1,635

edits

@@ Line 4: / Line 4: @@
 |Feature status=In progress
 |Feature version=Firefox 10
-|Feature health=At risk
+|Feature health=OK
 |Feature status note=Specced out, engineering work starting
 }}
@@ Line 17: / Line 17: @@
 * Can mirrors handle the "instant" demand for an add-on across the entire user base?
 * Would mirrors like this more than a point release?
+** Less data but a lot quicker uptake
 |Feature overview=There are many issues that affect our audience after release that shouldn't require a full Firefox update.
@@ Line 22: / Line 23: @@
 |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 have a problem with add-ons that require a rebuild of add-on metadata. We issue an empty update
+* We have a problem with add-ons that require a rebuild of add-on metadata. We issue an empty add-on
 * We have an issue that only affects Italian builds. Rather than issue a new Firefox update to everyone, we ship an update to the add-on which only acts when the locale is set to Italian
-* We want to blocklist a widely used plugin. We
+* We want to blocklist a widely used plugin. We turn on crude click-to-play and whitelist it for known good websites
 * 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
@@ Line 47: / Line 48: @@
 * 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
+* We should get sign-off on the fact that the add-on won't be treated specially and will show up in the add-on manager, can be disabled, etc
 |Feature security review=Things to cover:
 * How to make it so malicious add-ons can't use the same hiding mechanisms
@@ Line 55: / Line 57: @@
 * AMO webservices
 * Add-on manager general functionality
+Things to note:
+* Security fixes shipped this way will have way better uptake than a Firefox release
+* Security fixes can be shipped faster / before we have all the info and undone just as quickly
 |Feature privacy review=* Check with privacy team to see if add-ons give additional metrics by default we need to be aware of
-* Before issuing an update get privacy team to sign off
+* Before issuing an add-on update get privacy team to sign off
 |Feature localization review=* Should ship with all locales
 * Shouldn't be any localization by default
@@ Line 64: / Line 70: @@
 * QA needs to test the add-on works
 * QA needs to test the add-on can't be uninstalled
+* QA needs to comment on how this affects their testing matrix and load for a chemspill
+** QA should come up with the matrix substituting historical chemspill releases with the hotfix add-on
+|Feature operations review=* justdave needs to be looped in to answer the mirror questions
+* Need to loop AMO admins in on the increase of data
+* Need to loop metrics in as the add-on metadata (ADU, locale, disabled/enabled) may help them in other areas
+|Feature implementation notes=Mossop:
+"I've been tinkering a little with the add-on hotfix code and have something that works and passes the basic tests I've written so far. I had to make a choice and this we need to make sure we're aware of the implications of that before I go much further. For looking up available hotfixes from AMO I can either use the metadata API call or the usual update check call. They have some pros and cons:
+The update check call has been standard for a lot longer than the metadata API. Should we ever transition this to some other server it feels like the version check format is likely to need less change over time compared to the metadata API.
+The metadata API only returns the latest version of an add-on, regardless of its compatibility with the current version of Firefox. This means that we wouldn't be able to have a hotfix for Firefox 9 available at the same time as a hotfix for Firefox 10 (unless they were the same add-on). The version check call I believe in AMO (and certainly possible according to the format) can return multiple versions of an add-on to get around this.
+In terms of code complexity it ends up being slightly more complex to use the metadata API call for this, it's due to stupid reasons but I'd have to move some code around to make compatibility checking work right so making the patch more complex than perhaps we'd like.
+The update check call includes a number of parameters in the url based on the existing installed version of an add-on. Since the hotfix won't actually be installed normally I'll have to stub these out with fixed values. Not really a problem but might look odd in some metrics.
+The update check call is what drives an add-on's usage stats on AMO, not sure if that is a god or bad thing.
+Based on all that so far I'm leaning towards using the update check call as it seems to suit our needs better right now."
+|Feature landing criteria=* Need to test the add-on in a real-world scenario during aurora / beta
 }}
 {{FeatureInfo
 |Feature priority=Unprioritized
+|Feature list=Desktop
+|Feature project=Silent Update
+|Feature engineering team=Desktop front-end
 }}
 {{FeatureTeamStatus}}