xpcshell: JS chrome files don't load, because chrome:// not available

RESOLVED WORKSFORME

Status

()

Core
XPConnect
RESOLVED WORKSFORME
8 years ago
7 years ago

People

(Reporter: BenB, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
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();
}
(Reporter)

Comment 1

8 years ago
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.
Blocks: 448861, 552344
OS: Linux → All
Hardware: x86 → All
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 :-/
No longer blocks: 552344
No longer blocks: 448861
'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://*'?
Depends on: 555715
Keywords: testcase-wanted
Summary: xpcshell: JS modules and JS chrome files don't load, because chrome:// and resource://app/ not available → xpcshell: JS chrome files don't load, because chrome:// not available
(Reporter)

Comment 4

7 years ago
I did. The bug starts with it.
Keywords: testcase-wanted
(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?
(Reporter)

Comment 7

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 8

7 years ago
> Could the chrome:// part go into xpcshell head.js? (see resource://test/)

FWIW, that's what this bug wants to do, yes.
You need to log in before you can comment on or make changes to this bug.