Last Comment Bug 690418 - ChromeWorker global inaccessible out of DOM scope
: ChromeWorker global inaccessible out of DOM scope
Status: VERIFIED FIXED
[inbound]
: addon-compat, dev-doc-complete
Product: Core
Classification: Components
Component: DOM (show other bugs)
: unspecified
: All All
: -- major (vote)
: mozilla10
Assigned To: Ben Turner (not reading bugmail, use the needinfo flag!)
:
:
Mentors:
: 685916 (view as bug list)
Depends on: new-web-workers
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-29 10:24 PDT by Jorge Villalobos [:jorgev]
Modified: 2015-04-02 07:17 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
+
fixed
fixed
fixed


Attachments
Patch, v1 (31.20 KB, patch)
2011-10-12 17:31 PDT, Ben Turner (not reading bugmail, use the needinfo flag!)
jonas: review+
christian: approval‑mozilla‑aurora+
christian: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description Jorge Villalobos [:jorgev] 2011-09-29 10:24:54 PDT
The patch in bug 649537 removed the nsIWorkerFactory interface and replaced it with the ChromeWorker constructor. However, this constructor is only available as a global in the DOM. There's no way to instantiate it from a JSM or a restartless add-on script unless you get a window object.

On a (possibly) related note, the XPCOM object (https://developer.mozilla.org/en/DOM/ChromeWorker#Using_the_XPCOM.C2.A0object) is not available to ChromeWorkers in Firefox 8 either.

These are major problems for add-on compatibility, so I recommend that this is fixed in Firefox 8.
Comment 1 Andrew Williamson [:eviljeff] 2011-09-29 10:38:03 PDT
(In reply to Jorge Villalobos [:jorgev] from comment #0)
> On a (possibly) related note, the XPCOM object
> (https://developer.mozilla.org/en/DOM/ChromeWorker#Using_the_XPCOM.C2.
> A0object) is not available to ChromeWorkers in Firefox 8 either.

for reference, the XPCOM object was added to ChromeWorkers in bug 618484
Comment 2 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-29 10:38:44 PDT
(In reply to Jorge Villalobos [:jorgev] from comment #0)
> The patch in bug 649537 removed the nsIWorkerFactory interface and replaced
> it with the ChromeWorker constructor. However, this constructor is only
> available as a global in the DOM. There's no way to instantiate it from a
> JSM or a restartless add-on script unless you get a window object.

We should fix this, for 8, IMO.

> On a (possibly) related note, the XPCOM object
> (https://developer.mozilla.org/en/DOM/ChromeWorker#Using_the_XPCOM.C2.
> A0object) is not available to ChromeWorkers in Firefox 8 either.

This is by design.  There's no XPConnect on worker threads anymore, so there's no way to get at arbitrary XPCOM objects anymore.
Comment 3 Jorge Villalobos [:jorgev] 2011-09-29 10:48:33 PDT
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #2)
> > On a (possibly) related note, the XPCOM object
> > (https://developer.mozilla.org/en/DOM/ChromeWorker#Using_the_XPCOM.C2.
> > A0object) is not available to ChromeWorkers in Firefox 8 either.
> 
> This is by design.  There's no XPConnect on worker threads anymore, so
> there's no way to get at arbitrary XPCOM objects anymore.

Adding dev-doc-needed, since the documentation is out of date in this regard.
Comment 4 Kris Maglione [:kmag] 2011-09-29 13:12:56 PDT
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #2)
> > On a (possibly) related note, the XPCOM object
> > (https://developer.mozilla.org/en/DOM/ChromeWorker#Using_the_XPCOM.C2.
> > A0object) is not available to ChromeWorkers in Firefox 8 either.
> 
> This is by design.  There's no XPConnect on worker threads anymore, so
> there's no way to get at arbitrary XPCOM objects anymore.

Is there a reason for this change, and a bug number? This is the
kind of change that the add-ons team really needs to know about long
before it hits the Aurora branch. That functionality was added to
chrome workers to mitigate the breakage of add-ons by the removal of
JS threading, after quite a lot of coordination with Jorge and other
members of the add-ons team. It's been present for multiple releases
already, and people have been relying on it. We really need time to
assess and find ways to mitigate the impact of these kinds of
changes.
Comment 5 Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-29 13:15:24 PDT
That would be Bug 649537.
Comment 6 Johnny Stenback (:jst, jst@mozilla.com) 2011-09-30 23:59:15 PDT
Ben, care to have a look at this?
Comment 7 Johnny Stenback (:jst, jst@mozilla.com) 2011-10-10 15:01:00 PDT
Tracking for 8. We need to either fix this (soon!), or make a conscious decision to ship with this.
Comment 8 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-10-12 17:31:38 PDT
Created attachment 566699 [details] [diff] [review]
Patch, v1

Patch!

It's like 5 lines. The tests are beefy.
Comment 9 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-10-14 09:01:44 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/0cf085118da2
Comment 10 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-10-14 12:47:29 PDT
Also needed https://hg.mozilla.org/integration/mozilla-inbound/rev/c6770095945e to fix some other tests that looked for addons with '@tests.mozilla.org' in their id...
Comment 12 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-10-17 07:55:52 PDT
*** Bug 685916 has been marked as a duplicate of this bug. ***
Comment 13 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-10-17 08:00:22 PDT
Comment on attachment 566699 [details] [diff] [review]
Patch, v1

We should definitely put this on the branches too, it corrects a rather bad problem for extensions. The actual code changes are quite small.

The tests for this change however can't land on branches unless we want to try to push bug 688300 and bug 688330 as well. Since the worker code is identical on trunk and branches I think tests passing on trunk should be a reasonably good indicator of the patch succeeding on branches too?
Comment 14 christian 2011-10-18 10:15:49 PDT
Comment on attachment 566699 [details] [diff] [review]
Patch, v1

Approved for branches. I don't think we need to port the tests.
Comment 16 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-10-18 11:56:37 PDT
Sheppy, for this change, we need to document that addons must use absolute urls to load their workers, and that those urls have to have a chrome:// or resource:// protocol. file:// is not accepted. Addons that wish to use file:// urls must first register a resource replacement path. I have code for this in the test addon in the patch for this bug, but the relevant bits are:

  var fileuri = Services.io.newFileURI(file);
  Services.io.getProtocolHandler("resource").
              QueryInterface(Ci.nsIResProtocolHandler).
              setSubstitution("my-cool-addon", fileuri);
  var worker = new Worker("resource://my-cool-addon/worker.js");

Make sense?
Comment 18 Chris Mills (Mozilla, MDN editor) [:cmills] 2015-01-30 08:30:59 PST
Added a note (including Ben's helpful explanation) to

https://developer.mozilla.org/en-US/docs/Web/API/ChromeWorker

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