706777 - Automatically repopulate AddonRepository database on application upgrade

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

When the schema of AddonRepository's database has a significant change, there can be new rows or tables that make an important contribution to the functioning of the Addons Manager - such as compatibility overrides. Ideally, we want to populate that with fresh data as soon as possible.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: WiP v1

Dave, do you see any downside to this approach?

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 578957 [details] [diff] [review]
WiP v1

Trying the update.js/selectAddons.js route, as suggested on IRC.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v1

Comment 4

[Dave Townsend [:mossop]]

Comment on attachment 579041 [details] [diff] [review]
Patch v1

Review of attachment 579041 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/mozapps/extensions/content/selectAddons.js
@@ +128,1 @@
>  

Looks like you left two blank lines here

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Fixed re-disabling the cache at the end of the test.

https://hg.mozilla.org/integration/fx-team/rev/109bb6c0e72a

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 579041 [details] [diff] [review]
Patch v1

Preemptively requesting approval (it's not merged into central yet). Important piece of the compatible-by-default story, required for enabling it on a release version.

Comment 7

[Lawrence Mandel [:lmandel] (use needinfo)]

This should land on M-C before Aurora approval is granted.

Comment 8

[Alex Keybl [:akeybl]]

Comment on attachment 579041 [details] [diff] [review]
Patch v1

[Triage Comment]
Approving low-risk add-ons default to compatible bugs for Aurora with the understanding that we're going to come up with explicit methods of tracking any regressions in aurora/beta related to this and stay on top of them.

Please land on aurora only when this has been landed on m-c.

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/mozilla-central/rev/109bb6c0e72a

Comment 10

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Note: The patch here is dependent on the patch in bug 693906. And that can't land on Aurora until bug 707328 can also land on Aurora.

Dependency chains are fun.

Comment 11

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/31127fa275a9

Comment 12

[u279076]

Is this something QA can verify?

Comment 13

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Kinda... it's a little awkward to do so at the moment, because AMO only has one compatibility override (that I know of), and that's for Addon Compatibility Reporter v1.0 and below. But there's v1.0.1 and v1.0.2 out now, which don't have a compatibility override... so you have to make sure Firefox doesn't automatically upgrade to those versions.

1. Start Firefox 9 
2. Disable addon update
3. Install ACR v1.0
4. Disable ACR (useful because that version disables compatible-by-default)
4. Upgrade to Firefox 10 or higher
5. ACR should be marked as incompatible

Without the fix from this bug, ACR would only be made incompatible after the first background update check after the upgrading to Firefox 10 or newer.

Comment 14

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0
Mozilla/5.0 (X11; Linux x86_64; rv:11.0a2) Gecko/20120102 Firefox/11.0a2

Verified on Firefox 10 (Beta 2) and 11 (Aurora) on ubuntu 11.10, Mac OS 10.6 and Windows 7.

Disabled ACR version 1.0 is listed as incompatible after the upgrade.