If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

make xpcshell load chrome from GRE dir

RESOLVED FIXED

Status

()

Core
XPConnect
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: ted, Assigned: Benjamin Smedberg)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
Created attachment 367207 [details]
log of full xpcshell test run from packaged build+tests

Using the patch in attachment 367205 [details] [diff] [review] from bug 421611, I packaged a build and all its tests, then unpacked the tests on the same machine and ran them like so:
cat xpcshell/tests/all-test-dirs.list  | sed "s|^|./xpcshell/tests/|" | xargs python xpcshell/runxpcshelltests.py --keep-going --xre-path=./firefox/ ./bin/xpcshell

A lot of tests are failing. I'm not sure if it's problems with the tests or files that I'm not packaging, or what. I'll attach the full test log and try to narrow it down from there.
(Reporter)

Comment 1

9 years ago
Joel, are any of these failures you've seen in Fennec testing?
test_bug455213.js is failing because it isn't finding the plugins directory alongside the CurProcD. Presumably there is some new way of finding the binary directory of firefox?
(Reporter)

Comment 3

9 years ago
"GreD" will get the Firefox dir in this case.
I have done this for Fennec and run the tests on the device.  Here is a list of tests that fail on Fennec:
http://people.mozilla.com/~jmaher/xpcshell.html

there are 26 tests that fail.  I need to update the list a bit with some adjusted bug numbers which should happen soon.
(Reporter)

Comment 5

9 years ago
I changed the test packaging to put the test plugin in bin/plugins (next to xpcshell), and that fixes that particular test.
(Reporter)

Comment 6

9 years ago
http://mavra.perilith.com/~luser/latest-teds-builds/

There's a mac build and test package. I don't think I can fix all these tests myself.
python -u xpcshell/runxpcshelltests.py --xre-path=./firefox/ ./bin/xpcshell ./xpcshell/tests/test_update/unit/
will run that directory of tests.
(Reporter)

Comment 7

9 years ago
Looking into this test:
parser/xml/test/unit/test_parser.js
It appears that the test is in fact working correctly, but the error handler is called with an empty string for an error message, which the test treats as no error. I think the stringbundle isn't being loaded properly.
(Assignee)

Comment 8

9 years ago
What's happening appears to be that xpcshell isn't loading chrome from the GRE dir, only the app dir, which in this case is pretty useless. See http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsXREDirProvider.cpp#709 and http://mxr.mozilla.org/mozilla-central/source/chrome/src/nsChromeRegistry.cpp#1252

There are a couple options we can try:

* have xpcshell provide NS_CHROME_MANIFESTS_FILE_LIST
* have the chrome registry use a better default (include gredir/chrome by default)
* stick xpcshell in the appdir instead of a separate test dir, which we've been avoiding so far
(Reporter)

Comment 9

9 years ago
(In reply to comment #8)
> * stick xpcshell in the appdir instead of a separate test dir, which we've been
> avoiding so far

This seems to remove most of the test failures I was seeing. The downside is that I not only need to copy xpcshell, I need to copy test_necko.xpt and httpd.js to firefox/components, since the tests rely on those.

It takes me down to 4 failures which are easily explained:
test_punycodeURIs.js - this test expects to find the WriteArgument executable, which isn't currently packaged in the app or test package (we should package it with the tests)
http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/tests/unit/test_punycodeURIs.js#106

test_bug455213.js: This is a plugin unittest, and expects to find the test plugin somewhere (which isn't in the app dir, of course):
http://mxr.mozilla.org/mozilla-central/source/modules/plugin/test/unit/test_bug455213.js#111
I'm not really sure how to fix this one, short of copying the test plugin to appdir/plugins.

test_nsIProcess.js: Also expects to find a couple of test executables:
http://mxr.mozilla.org/mozilla-central/source/xpcom/tests/unit/test_nsIProcess.js#61
Easy enough to make them get copied to the test dir.

test_bug378839.js: The tests dir contains strres.properties, which the test expects to be able to load, but this is a test .properties file that isn't shipped with the app. I think we can instead put it in the test dir, and make the test register its own resource path to load the bundle from. (Or use a file URL if you can load bundles from those.)
http://mxr.mozilla.org/mozilla-central/source/intl/strres/tests/unit/test_bug378839.js#35
(Reporter)

Comment 10

9 years ago
Comment on attachment 367207 [details]
log of full xpcshell test run from packaged build+tests

bsmedberg's comment explains all the other failures, we'll have to fix the underlying problem, clearly.
Attachment #367207 - Attachment is obsolete: true
(Reporter)

Comment 11

9 years ago
(In reply to comment #9)
> test_bug455213.js: This is a plugin unittest, and expects to find the test
> plugin somewhere (which isn't in the app dir, of course):
> http://mxr.mozilla.org/mozilla-central/source/modules/plugin/test/unit/test_bug455213.js#111
> I'm not really sure how to fix this one, short of copying the test plugin to
> appdir/plugins.

I fixed this in my existing patch before by putting it in bin/plugins, next to xpcshell. Copying it to firefox/plugins would fix the test, but it's kind of a hassle. :-/
(Reporter)

Comment 12

9 years ago
Ok, If I copy:
bin/xpcshell -> firefox/
bin/components/httpd.js -> firefox/components
bin/components/test_necko.xpt -> firefox/components
bin/plugins/libnptest.so -> firefox/plugins

Then run:
cat xpcshell/tests/all-test-dirs.list  | sed "s|^|./xpcshell/tests/|" | xargs python -u xpcshell/runxpcshelltests.py --keep-going ./firefox/xpcshell

All the tests pass for me now on Linux.
(Reporter)

Comment 13

9 years ago
Morphing this bug to cover bsmedberg's suggestions from comment 8. The workaround is working, but it sucks.
Assignee: ted.mielczarek → nobody
Blocks: 421611
Status: ASSIGNED → NEW
Component: TUnit → XPConnect
Product: Testing → Core
QA Contact: tunit → xpconnect
Summary: sort out xpcshell test failures when run from packaged build → make xpcshell load chrome from GRE dir
Version: unspecified → Trunk
(Assignee)

Updated

9 years ago
Assignee: nobody → benjamin
(Assignee)

Comment 14

8 years ago
Created attachment 382913 [details] [diff] [review]
Load chrome from the GRE directory, rev. 1

I've verified that this works manually... the directory service changes were required because by golly the directory service was appending "components" to the GRE directory without cloning it!
Attachment #382913 - Flags: review?(ted.mielczarek)
Blocks: 486570
(Reporter)

Comment 15

8 years ago
Comment on attachment 382913 [details] [diff] [review]
Load chrome from the GRE directory, rev. 1

Seems sensible, yeah. Would be nice to have a test for this, although testing it in the existing xpcshell harness would be pretty difficult. Could probably do a custom test in check::.
Attachment #382913 - Flags: review?(ted.mielczarek) → review+
(Assignee)

Comment 16

8 years ago
http://hg.mozilla.org/mozilla-central/rev/19e12cf52506
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.