Last Comment Bug 546628 - xpcshell: JS chrome files don't load, because chrome:// not available
: xpcshell: JS chrome files don't load, because chrome:// not available
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 555715
  Show dependency treegraph
Reported: 2010-02-17 05:46 PST by Ben Bucksch (:BenB)
Modified: 2010-04-04 16:16 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Ben Bucksch (:BenB) 2010-02-17 05:46:19 PST
Create a file jsmodule.js:

Create a file jschrome.js:
dump("timeout is: " + TIMEOUT + "\n");

Then run:
$ ./mozilla/dist/bin/ ./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

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.

  let Cc = Components.classes;
  let Ci = Components.interfaces;
  let Cu = Components.utils;

  // Register resource://app/ URI
  let ios = Cc[";1"]
  let protocolHandler = ios.getProtocolHandler("resource")
  let cwd = Cc[";1"]
      .get("CurProcD", Ci.nsILocalFile);
  let curDirURI = ios.newFileURI(cwd);
  protocolHandler.setSubstitution("app", curDirURI);

  // register chrome://* URIs
  var cr = Cc[";1"]
Comment 1 User image Ben Bucksch (:BenB) 2010-02-17 05:57:21 PST
In the meantime, I documented this on MDC <>, but I really think that should not be necessary.
Comment 2 User image Serge Gautherie (:sgautherie) 2010-03-14 18:28:02 PDT
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 :-/
Comment 3 User image Serge Gautherie (:sgautherie) 2010-04-01 19:49:02 PDT
'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://*'?
Comment 4 User image Ben Bucksch (:BenB) 2010-04-02 01:39:22 PDT
I did. The bug starts with it.
Comment 5 User image Serge Gautherie (:sgautherie) 2010-04-04 10:33:17 PDT
(In reply to comment #4)

Hum, I see no explicit chrome:// URI...

Anyway, could it be that your path is wrong?
See for example
Comment 6 User image Serge Gautherie (:sgautherie) 2010-04-04 10:39:27 PDT
(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?
Comment 7 User image Ben Bucksch (:BenB) 2010-04-04 14:55:41 PDT
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
<>, 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.
Comment 8 User image Ben Bucksch (:BenB) 2010-04-04 16:16:12 PDT
> Could the chrome:// part go into xpcshell head.js? (see resource://test/)

FWIW, that's what this bug wants to do, yes.

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