700988 - BRANCH_REGEXP is not defined in AddonRepository.jsm - Add-on manager broken on Aurora branch

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Mark Banner (:standard8)]

Attachment: The fix

Bug 581065 did a channel dependent change to AddonRepository.jsm:

#ifdef MOZ_COMPATIBILITY_NIGHTLY
const PREF_CHECK_COMPATIBILITY = PREF_CHECK_COMPATIBILITY_BASE +
                                 ".nightly";
#else
const PREF_CHECK_COMPATIBILITY = PREF_CHECK_COMPATIBILITY_BASE + "." +
                                 Services.appinfo.version.replace(BRANCH_REGEXP, "$1");
#endif

However BRANCH_REGEXP isn't defined in this file (and its a module).

So as soon as you get Gecko 10 onto a aurora, beta or release update channel, it'll break.

The Firefox unit test builders don't see this because they use the default channel, and so they use the first part of the ifdef which doesn't rely on BRANCH_REGEXP.

This is probably therefore a blocker to us releasing nightly updates on Aurora.

The solution I'm proposing is to define BRANCH_REGEXP for now. A longer term solution might be to not have the channel dependency, maybe a version check or something, and hence it would be more likely to break tests - but I think that's for consideration in a follow-up.

Comment 1

[LegNeato]

These are bad bad bad. This type of bug is exactly why I have been fighting behavior switching between beta and release FWIW...ticking time bombs...

Comment 2

[Joel Maher ( :jmaher ) (UTC -8)]

this appears to be causing all the automation which requires specialpowers to fail:
Error: ERROR addons.manager: Exception loading default provider "resource://gre/modules/XPIProvider.jsm": [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: resource://gre/modules/AddonManager.jsm :: <TOP_LEVEL> :: line 353"  data: no]
Source File: resource://gre/modules/AddonManager.jsm
Line: 353

Comment 5

[Rain [:rain1] (inactive)]

I filed bug 700985 about not depending on the update channel in code.

Comment 6

[Dave Townsend [:mossop]]

Comment on attachment 573154 [details] [diff] [review]
The fix

Looks good, hopefully we can just remove all this stuff once default to compatible is turned on.

Comment 7

[Mark Banner (:standard8)]

Checked in on inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/e81888aef700

Comment 8

[Mark Banner (:standard8)]

Comment on attachment 573154 [details] [diff] [review]
The fix

Requesting approval for aurora as this should fix the add-on manager there. Although this has only just landed on inbound, this doesn't actually affect anything there as the code that uses it is ifdeffed out on inbound & central.

Comment 9

[Alex Keybl [:akeybl]]

Comment on attachment 573154 [details] [diff] [review]
The fix

[Triage Comment]
Fixes broken add-on manager. Approving for Aurora.

Comment 10

[Phil Ringnalda (:philor)]

(Well, not FIXED in the sense of having been merged to m-c, but that's a no-op so I'm not going to reopen over that. But Aurora is unbusted.)

Comment 11

[Jens Hatlak (:InvisibleSmiley)]

FTR: http://hg.mozilla.org/releases/mozilla-aurora/rev/3557fb5c8f9f

Comment 12

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/e81888aef700

Comment 13

[u279076]

Is this something QA can verify?

Comment 14

[Blair McBride [:Unfocused] (UNAVAILABLE)]

1. Run Aurora (or Beta)
2. If Add-ons Manager works (UI lists any addons), this is verified

Comment 15

[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 Mac OS 10.6, Ubuntu 11.10, Windows 7 in Aurora (firefox 11) and Beta 2 (Firefox 10) with steps in comment 14. 
Add-ons are listed as expected.