We now have a module loader for chrome workers. However, it depends on XHR, Blob and URL.createObjectURL, so using it in a xpcshell causes "interesting" effects (depending on the circumstances, this ranges from modules not found to assertion failures). Unfortunately, this means that the module loader is pretty unusable, e.g. we cannot port OS.File to the module loader without breaking a gazillion of xpcshell tests. Opening this bug to find a way around this.

Cc-ing bholley and bent to see if they have an idea.

In general, you're going to have a hard time if you try to use DOM stuff from XPCShell. There's spotty support for certain DOM objects (like XHR) without an associated DOM window, and we use it in certain special cases (like sandboxes). But in general, I think you're better off abstracting the functionality you want into some kind of interfaces, and then implementing that both in workers (using the functions you mentioned) and in XPCShell (using XPCOM).

Andrea is fixing the URL.createObjectURL in bug 883784. Jan has a patch that adds Blob support to xpcshell, but that hasn't been filed yet.

(In reply to Bobby Holley (:bholley) from comment #2) > In general, you're going to have a hard time if you try to use DOM stuff > from XPCShell. There's spotty support for certain DOM objects (like XHR) > without an associated DOM window, and we use it in certain special cases > (like sandboxes). But in general, I think you're better off abstracting the > functionality you want into some kind of interfaces, and then implementing > that both in workers (using the functions you mentioned) and in XPCShell > (using XPCOM). That's going to be very difficult. The objective here is to port OS.File to the chrome worker module loader. OS.File itself is used just about everywhere in toolkit/ and browser/, by many modules that themselves have xpcshell tests. Porting OS.File to XPCOM just for the sake of xpcshell would be suicidal - i.e. having one execution path for testing and one for release doesn't quite make it. Porting a sizeable chunk of all xpcshell tests to mochitests would probably not be a good idea either. Now, if there is a way to have a replacement for XHR et al. in Chrome Workers that doesn't go through DOM, I am interested. A subset of OS.File itself could certainly be used for that purpose. Is that the solution you suggest?

Worker-XHR in XPCShell is currently supported.

(In reply to David Rajchenbach Teller [:Yoric] from comment #4) > That's going to be very difficult. The objective here is to port OS.File to > the chrome worker module loader. > Porting OS.File to XPCOM just for the sake of xpcshell would be suicidal That was not my suggestion. The problem described in comment 0 is that the worker module loader relies on XHR, Blob, and URL, which are DOM constructs. So I'm suggesting that we make the module loader portable between Chrome Workers and XPCShell. > OS.File itself is used just about > everywhere in toolkit/ and browser/, by many modules that themselves have > xpcshell tests. Right, because IIUC OS.File is already DOM agnostic (i.e. it can run in a JSM). As such, it's not clear to me what "Porting OS.File to XPCOM" means.

(In reply to Bobby Holley (:bholley) from comment #6) > (In reply to David Rajchenbach Teller [:Yoric] from comment #4) > > That's going to be very difficult. The objective here is to port OS.File to > > the chrome worker module loader. > > Porting OS.File to XPCOM just for the sake of xpcshell would be suicidal > > That was not my suggestion. The problem described in comment 0 is that the > worker module loader relies on XHR, Blob, and URL, which are DOM constructs. > So I'm suggesting that we make the module loader portable between Chrome > Workers and XPCShell. > > > OS.File itself is used just about > > everywhere in toolkit/ and browser/, by many modules that themselves have > > xpcshell tests. > > Right, because IIUC OS.File is already DOM agnostic (i.e. it can run in a > JSM). It is DOM agnostic at the moment. But the source code is full of hacks to work around the lack of a module loader, so if we end up with a DOM-bound module loader, OS.File will become DOM-bound. Of course, as you mention, the idea is to either write a DOM-independent module loader. For the module loader, I need the ability to: 1. load a resource:// uri synchronously; 2. inject a source code contained in a string at the toplevel with an identifiable uri (to have somewhat readable stack traces). * I am currently using XHR for 1., but I can certainly rewrite that code in xpcom and bind it through js-ctypes. Not very nice, but possible. * I am currently using URL.createObjectURL for 2. I could use |eval()| or |Function()| for the same purpose, but I would lose the identifiable uri, which would make stack traces unusable, and would compromise the module loader considerably. Alternatively, I suppose I could extend the WorkerScope of chrome workers with a mozImportScriptString, or something such, that would mimic importScript() but accept a string and a uri. I seem to remember that xpcshell used to have this feature, so that's certainly possible. So, what do you suggest? > As such, it's not clear to me what "Porting OS.File to XPCOM" means. Never mind, I was replying to something I had misunderstood.

(In reply to David Rajchenbach Teller [:Yoric] from comment #7) > * I am currently using XHR for 1., but I can certainly rewrite that code in > xpcom and bind it through js-ctypes. Not very nice, but possible. I'm not suggesting that we modify the implementation of the ChromeWorker module loader - just that we abstract those bits into a helper that we can implement in two ways (xpcshell-style and ChromeWorker-style) depending on the environment. > Alternatively, I suppose I could extend the WorkerScope of chrome workers > with a mozImportScriptString, or something such, that would mimic > importScript() but accept a string and a uri. I seem to remember that > xpcshell used to have this feature, so that's certainly possible. That would work too, yes. I don't know enough about ChromeWorker to say whether we can/should add APIs like this.

Well, this seems to work now. Thanks for the quick bugfixes, everybody.