components.list picks up some components from test/sample directories that we don't ever ship, leading to a bunch of failed component load attempts in non-test builds. As an example, here's a list taken from the console spew of a Windows nightly: tp-cmdline.js nsProgressDialog.js testdynamic.dll MyService.dll xpcomsample.dll nsSample.js httpd.js reftest-cmdline.js

Comment on attachment 411256 [details] [diff] [review] Customize FINAL_TARGET for samples and tests so that we still load them, but they are in different directories, rev. 1 You'll need to fix xpcshell packaging: http://mxr.mozilla.org/mozilla-central/source/testing/xpcshell/Makefile.in#69 as well as Mochitest packaging: http://mxr.mozilla.org/mozilla-central/source/testing/mochitest/Makefile.in#118 It's sort of a mess. Also, I'm not exactly sure, but I think the packaged test builds still copy all the xpcshell binaries into the app dir (bug 486570, because bug 483202 wasn't fixed when we started running them). We might need to fix that before landing this. Otherwise this looks good. I wish we didn't have all this stuff getting installed to dist/bin in general, but that's a larger thing to fix.

The change in print-manifest-dirs.py was necessary because it fails when building from a relative srcdir.

Comment on attachment 413353 [details] [diff] [review] Customize FINAL_TARGET for samples and tests so that we still load them, but they are in different directories, rev. 2 I wish the try server did packaged unit tests, so I could tell you to test it there.

I just discovered this bug in SeaMonkey. [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20091216 SeaMonkey/2.1a1pre] (comm-central-trunk-win32/1260970429) (W2Ksp4) { Failed to load XPCOM component: ...\components\tp-cmdline.js Failed to load XPCOM component: ...\components\testdynamic.dll Failed to load XPCOM component: ...\components\MyService.dll Failed to load XPCOM component: ...\components\xpcomsample.dll Failed to load XPCOM component: ...\components\nsSample.js Failed to load XPCOM component: ...\components\httpd.js Failed to load XPCOM component: ...\components\xpctest.dll Failed to load XPCOM component: ...\components\reftest-cmdline.js Failed to load XPCOM component: ...\components\testcrasher.dll }

Shouldn't this be landed ?

Landing this requires updating Talos at least, which I don't have time to work on, so no.

After applying the already attached patch, a huge load of xpcshell tests fail because they fail to load the httpd.js component. Fixing runxpcshelltests.py to point at the right place fixes this, *but* there is one remaining problem: test_load_httpd_js.js fails because, not loading the typelib, it doesn't know Components.interfaces.nsIHttpServer.

(In reply to comment #9) > Fixing runxpcshelltests.py to point at the right place fixes this, *but* there > is one remaining problem: test_load_httpd_js.js fails because, not loading the > typelib, it doesn't know Components.interfaces.nsIHttpServer. Question is: shouldn't component loading load the typelibs from distribution bundles ?

(In reply to comment #10) > Question is: shouldn't component loading load the typelibs from distribution > bundles ? Answering to myself: when using the extensions manager, the typelibs are properly loaded.

In the end, I don't know how to fix test_load_httpd_js.js. Maybe removing it is enough. It is pretty much pointless, as a lot of other tests fail if httpd.js is not loadable.

Please don't remove it. It's a sort of meta-test, so that things fail obviously if core test harness functionality breaks. Without test_necko.xpt being loaded, I would expect other tests might fail (or at least, things will not work as expected).

I guess that now components.list is gone, this bug can be closed. What should it be marked ? WORKSFORME ? INVALID ?