Created attachment 573154 [details] [diff] [review] 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.
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...
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
I filed bug 700985 about not depending on the update channel in code.
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.
Checked in on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/e81888aef700
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 on attachment 573154 [details] [diff] [review] The fix [Triage Comment] Fixes broken add-on manager. Approving for Aurora.
(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.)
Is this something QA can verify?
1. Run Aurora (or Beta) 2. If Add-ons Manager works (UI lists any addons), this is verified
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.