The default bug view has changed. See this FAQ.

ChromeWorker global inaccessible out of DOM scope

VERIFIED FIXED in Firefox 8

Status

()

Core
DOM
--
major
VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: jorgev, Assigned: Ben Turner (not reading bugmail, use the needinfo flag!))

Tracking

({addon-compat, dev-doc-complete})

unspecified
mozilla10
addon-compat, dev-doc-complete
Points:
---

Firefox Tracking Flags

(firefox7 unaffected, firefox8+ fixed, firefox9 fixed, firefox10 fixed)

Details

(Whiteboard: [inbound])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
tracking-firefox8: --- → ?
(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
(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.
(Reporter)

Comment 3

6 years ago
(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.
Keywords: dev-doc-needed
(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.
That would be Bug 649537.

Updated

6 years ago
Depends on: 649537
Ben, care to have a look at this?
Assignee: nobody → bent.mozilla
Tracking for 8. We need to either fix this (soon!), or make a conscious decision to ship with this.
status-firefox10: --- → affected
status-firefox7: --- → unaffected
status-firefox8: --- → affected
status-firefox9: --- → affected
tracking-firefox8: ? → +
Created attachment 566699 [details] [diff] [review]
Patch, v1

Patch!

It's like 5 lines. The tests are beefy.
Attachment #566699 - Flags: review?(jonas)
Attachment #566699 - Flags: review?(jonas) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/0cf085118da2
Whiteboard: [inbound]
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...
https://hg.mozilla.org/mozilla-central/rev/0cf085118da2
https://hg.mozilla.org/mozilla-central/rev/c6770095945e
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Duplicate of this bug: 685916
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?
Attachment #566699 - Flags: approval-mozilla-beta?
Attachment #566699 - Flags: approval-mozilla-aurora?

Comment 14

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

Approved for branches. I don't think we need to port the tests.
Attachment #566699 - Flags: approval-mozilla-beta?
Attachment #566699 - Flags: approval-mozilla-beta+
Attachment #566699 - Flags: approval-mozilla-aurora?
Attachment #566699 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/bd7b78fc45bd
https://hg.mozilla.org/releases/mozilla-beta/rev/df9841857c9c
status-firefox10: affected → fixed
status-firefox8: affected → fixed
status-firefox9: affected → fixed
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

6 years ago
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
Status: RESOLVED → VERIFIED
Added a note (including Ben's helpful explanation) to

https://developer.mozilla.org/en-US/docs/Web/API/ChromeWorker
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.