As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
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!)
:
: Andrew Overholt [:overholt]
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 User image 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 User image 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 User image 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 User image 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 User image 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 User image Kyle Huey [:khuey] (Exited; not receiving bugmail, email if necessary) 2011-09-29 13:15:24 PDT
That would be Bug 649537.
Comment 6 User image Johnny Stenback (:jst, jst@mozilla.com) 2011-09-30 23:59:15 PDT
Ben, care to have a look at this?
Comment 7 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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.