Last Comment Bug 701193 - xpcshell-tests for add-on manager broken when update channel is set to aurora/beta/release
: xpcshell-tests for add-on manager broken when update channel is set to aurora...
Status: RESOLVED FIXED
[qa-]
:
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla11
Assigned To: Geoff Lankow (:darktrojan)
:
: Andy McKay [:andym]
Mentors:
Depends on:
Blocks: 581065
  Show dependency treegraph
 
Reported: 2011-11-09 14:22 PST by Mark Banner (:standard8, afk until Dec)
Modified: 2011-12-28 14:13 PST (History)
8 users (show)
geoff: in‑testsuite-
geoff: in‑litmus-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
fix (2.64 KB, patch)
2011-11-09 15:11 PST, Geoff Lankow (:darktrojan)
dtownsend: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Mark Banner (:standard8, afk until Dec) 2011-11-09 14:22:23 PST
Following on from the fixes in bug 700988, xpcshell tests are still broken when the update channel is set to one of aurora, beta, or release. This means our aurora nightly tests fail.

Typical example:

TEST-UNEXPECTED-FAIL | /buildbot/comm-aurora-linux-opt-unittest-xpcshell/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_AddonRepository.js | test failed (with xpcshell return code: 3), see following log:
>>>>>>>
uncaught exception: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]"  nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)"  location: "JS frame :: /buildbot/comm-aurora-linux-opt-unittest-xpcshell/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/head_addons.js :: <TOP_LEVEL> :: line 15"  data: no]
<<<<<<<

I've tracked this down to this line of code:

const PREF_CHECK_COMPATIBILITY = PREF_CHECK_COMPATIBILITY_BASE + "." +
                                 Services.appinfo.version.replace(BRANCH_REGEXP, "$1");

Although bug 700988 has defined BRANCH_REGEXP, the issue now is Services.appinfo.version. If I replace that with a standard variable, the tests pass.

Now I get confused, head_addons.js clearly defines nsIXULAppInfo, but that doesn't seem to be getting picked up here, maybe it is too early in xpcshell's load process?

I'm not going to be able to work on this now, so if others can pick it up that'd be useful.
Comment 1 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-11-09 14:39:41 PST
The module is being imported at the top level, before createAppInfo() is called in the test, and the Services.appinfo.version reference is a global in the module, so it's run at import time. You could probably solve the issue by computing PREF_CHECK_COMPATIBILITY lazily...
Comment 2 Geoff Lankow (:darktrojan) 2011-11-09 15:11:16 PST
Created attachment 573342 [details] [diff] [review]
fix

I'll push this to try with the Makefile rigged to cause the bug.
Comment 3 Geoff Lankow (:darktrojan) 2011-11-10 00:11:01 PST
Looks like this is working fine on try, if you ignore the random oranges and the timebomb. I also filed bug 701298 which would cause orange in the same circumstances.
https://tbpl.mozilla.org/?tree=Try&rev=adab1f1bb32c
Comment 4 Geoff Lankow (:darktrojan) 2011-11-10 14:46:30 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/141b495ea4f5
Comment 5 Geoff Lankow (:darktrojan) 2011-11-10 14:50:13 PST
Comment on attachment 573342 [details] [diff] [review]
fix

This needs to land on aurora so it can actually pass its tests.
Comment 6 Marco Bonardo [::mak] 2011-11-11 02:23:10 PST
https://hg.mozilla.org/mozilla-central/rev/141b495ea4f5
Comment 7 Alex Keybl [:akeybl] 2011-11-11 15:00:59 PST
Comment on attachment 573342 [details] [diff] [review]
fix

[Triage Comment]
Fixes orange, approving for aurora.
Comment 8 Geoff Lankow (:darktrojan) 2011-11-11 15:49:11 PST
https://hg.mozilla.org/releases/mozilla-aurora/rev/e99625fee18a
Comment 9 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-12-28 14:13:37 PST
Marking qa- as there is nothing QA needs to verify here. Please set to qa+ if this is not the case.

Note You need to log in before you can comment on or make changes to this bug.