663625 - Error using XPCOM.createInstance in ChromeWorker to create a Javascript XPCOM component

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[poppertd]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

I wrote an XPCOM component in Javascript that I am trying to use in a ChromeWorker.  The ChromeWorker throws the following exception when I try to instantiate the component with XPCOM.createInstance:

"Error: Could not create the instance!"

The Javascript Error Console logs the following informational message:

"Attempt to use JS function on a different thread calling nsIFactory.createInstance. JS objects may not be shared across threads."

Using XPCOM.getService to create the component works, but I really need a new instance every time.

Reproducible: Always

Steps to Reproduce:
1. Create a basic XPCOM component in Javascript
2. Create an instance of the component in a ChromeWorker using XPCOM.createInstance

Actual Results:  
"Error: Could not create the instance!" is thrown.

Expected Results:  
An instance of the component should have been created and returned.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

The error message is correct - "JS objects may not be shared across threads".

Your factory here is implemented in JS and may not be shared across threads. I'm also not sure why getService works for you, but I would not count on it working perfectly or without random crashes.

We're probably going to remove this XPCOM object in the near future so I'd start thinking about other ways to do what you're trying to do via ctypes.

What are you trying to do?

Comment 2

[poppertd]

Thanks for the reply.  My backup plan was to try to make it work with getService, so I'm glad you told me that's not supported either.

My JS component is using ctypes to do some platform specific work in the background, so moving the code out of the XPCOM component and directly into the Worker is a possibility.  I was trying to avoid that because of the convenience XPCOM gave me in using Components.utils.import to import JSMs.  I have JSMs with js-ctype declarations (e.g. Kernel32.jsm, User32.jsm) that I also use in other parts of my application, so I really didn't want to have to redefine the ctypes libraries and functions.  Not to mention some of my JSMs import other JSMs (Kernel32.jsm imports WinNT.jsm), so it gets difficult trying to import the JSMs as JS libraries into the ChromeWorker using importScripts().  So if my ChromeWorker imported Kernel32.jsm and WinNT.jsm, WinNT.jsm would actually be loaded twice, which I expected, but some other quirky errors came up.

Is there any chance using JSMs in ChromeWorkers will be supported in the future?

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

ChromeWorkers should be able to import scripts from anywhere, JSMs included, via the 'importScripts' global function. I've never tested that explicitly, so there could be bugs, but I would expect that to work.

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

XPConnect was removed from the new web workers, I guess this can be closed?

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I guess so.