Create a file jsmodule.js: Components.utils.import("resource://app/modules/gloda/log4moz.js"); Create a file jschrome.js: load("mailnews/base/prefs/content/accountcreation/util.js"); load("mailnews/base/prefs/content/accountcreation/accountConfig.js"); load("mailnews/base/prefs/content/accountcreation/guessConfig.js"); dump("timeout is: " + TIMEOUT + "\n"); Then run: $ ./mozilla/dist/bin/run-mozilla.sh ./mozilla/dist/bin/xpcshell jsmodule.js and jschrome.js respectively. Actual result: 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 :: mailnews/base/prefs/content/accountcreation/guessConfig.js :: <TOP_LEVEL> :: line 42" data: no] Expected result: timeout is: 10 Reason: chrome:// and resource:// URIs are not registered as they are in the app. We have a minimal JS shell with |js|. The purpose of |xpcshell| is to allow to access XPCOM components and app resources from the commandline. As more functionality is moved from XPCOM to JS, we'll need JS modules and JS chrome files as well, increasingly. xpcshell should be able to use those without jumping through hoops. Implementation: { let Cc = Components.classes; let Ci = Components.interfaces; let Cu = Components.utils; // Register resource://app/ URI let ios = Cc["@mozilla.org/network/io-service;1"] .getService(Ci.nsIIOService); let protocolHandler = ios.getProtocolHandler("resource") .QueryInterface(Ci.nsIResProtocolHandler); let cwd = Cc["@mozilla.org/file/directory_service;1"] .getService(Ci.nsIProperties) .get("CurProcD", Ci.nsILocalFile); let curDirURI = ios.newFileURI(cwd); protocolHandler.setSubstitution("app", curDirURI); // register chrome://* URIs var cr = Cc["@mozilla.org/chrome/chrome-registry;1"] .getService(Ci.nsIChromeRegistry); cr.checkForNewChrome(); }

In the meantime, I documented this on MDC <https://developer.mozilla.org/en/XPConnect/xpcshell/WithJSModulesAndChrome>, but I really think that should not be necessary.

Could the chrome:// part go into xpcshell head.js? (see resource://test/) But that is too late for resource://app/: see bug 448861 and bug 552344. Modules are loaded during the registration process which happens before head.js is run :-/

'resource://app/*' were removed by bug 555715 ;-> (Please, update your MDC page accordingly.) Could you provide a testcase or point to an existing example of an issue with 'chrome://*'?

I did. The bug starts with it.

(In reply to comment #4) Hum, I see no explicit chrome:// URI... Anyway, could it be that your path is wrong? See for example http://mxr.mozilla.org/comm-central/source/mailnews/base/test/unit/head_mailbase.js http://mxr.mozilla.org/comm-central/source/mailnews/base/test/unit/test_junkingWhenDisabled.js

(In reply to comment #5) > Anyway, could it be that your path is wrong? I mean, do you actually have a ./mailnews/base/prefs/content/accountcreation/ directory?

I got the path from exactly from such examples you mentioned, and tried several paths. However, the examples you showed were JS modules. I needed to load chrome files. The point of this bug is that such relative file paths as you mentioned shouldn't be necessary. I should be able to just load chrome:// URLs as I can in the app. Interestingly enough, we did get it to work, see <http://mxr.mozilla.org/comm-central/source/mailnews/base/test/unit/test_autoconfigUtils.js#54>, so I might have done something else wrong here. However, note that we had to use subscriptloader and not load(). Anyways, I'll close the bug until I investigated further.

> Could the chrome:// part go into xpcshell head.js? (see resource://test/) FWIW, that's what this bug wants to do, yes.