690418 - ChromeWorker global inaccessible out of DOM scope

Status: VERIFIED FIXED

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

Description

[Jorge Villalobos [:jorgev] (he/him)]

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]]

(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 (Exited; not receiving bugmail, old account, do not use)]

(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] (he/him)]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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]]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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 (Exited; not receiving bugmail, old account, do not use)]

That would be Bug 649537.

Comment 6

[Johnny Stenback (:jst)]

Ben, care to have a look at this?

Comment 7

[Johnny Stenback (:jst)]

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!)]

Attachment: Patch, v1

Patch!

It's like 5 lines. The tests are beefy.

Comment 9

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/0cf085118da2

Comment 10

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

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 11

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/0cf085118da2
https://hg.mozilla.org/mozilla-central/rev/c6770095945e

Comment 13

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

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

[LegNeato]

Comment on attachment 566699 [details] [diff] [review]
Patch, v1

Approved for branches. I don't think we need to port the tests.

Comment 15

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/bd7b78fc45bd
https://hg.mozilla.org/releases/mozilla-beta/rev/df9841857c9c

Comment 16

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

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 17

[Ioana (away)]

The test cases verifying this fix are passing on all OSs:
https://tbpl.mozilla.org/php/getParsedLog.php?id=7149042&full=1&branch=services-central
https://tbpl.mozilla.org/php/getParsedLog.php?id=7148028&full=1&branch=services-central
https://tbpl.mozilla.org/php/getParsedLog.php?id=7150634&full=1&branch=services-central
https://tbpl.mozilla.org/php/getParsedLog.php?id=7149633&full=1&branch=services-central

Comment 18

[Chris Mills [:cmills]]

Added a note (including Ben's helpful explanation) to

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