New issue
Advanced search Search tips
Starred by 149 users
Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 692909

Participants' hotlists:

Show other hotlists

Other hotlists containing this issue:

Sign in to add a comment
HTML5 nested workers are not supported in chromium
Reported by, Jan 6 2010 Back to list
Chrome Version       : (33933)
Other browsers tested: Firefox 3.x: OK

What steps will reproduce the problem?
1.  Access a webpage with below content
  <title>Test threads fibonacci</title>
  <script type="text/javascript">
    var worker = new Worker("fibonacci1.js");
    worker.onmessage = function(event) {
      alert("Got: " +;
    worker.onerror = function(error) {
      alert("Worker error1: " + error.message);
      throw error;

What is the expected result?
  Alert with "Got: 55", just as firefox 3.X does.

What happens instead?
  Alert with "Worker error1: Uncaught ReferenceError: Worker is not 

601 bytes View Download
Labels: -Area-Undefined Area-WebKit WebKit-WebApps
Comment 2 by, Jan 11 2010
Labels: Mstone-5 karenianreview
Labels: -karenianreview
Status: Assigned
Dave - any chance you can look at this?
Comment 4 by, Jan 14 2010
Status: Available
   Alert with "Worker error1: Uncaught ReferenceError: Worker is not  defined".
means that the Worker object is not available in a Worker. This is true for all WebKit based browsers. Nested workers are not 
supported right now. 

Here are the relevant WebKit bugs (which currently are not moving forward):

Comment 5 by, Jan 14 2010
Summary: HTML5 nested workers are not supported in chromium (was: NULL)
I understand that the nested workers are the main problem. Thanks.
Besides that I think Chromium also leads to confusion in parameter passing.
Say, if I change the worker scripts to a non-nested

onmessage = function(event) {
  var n =;          

Firefox can returns 20 for the URL, but Chromium only returns 1010?
I wonder if Chromium just regards the parameter as a string?
I also see that Chromium has problem to handle multiple parameters of a worker.
Below test cases just run OK in Firefox but have problem in Chromium.

(1) In HTML:
    var args = {
     x: 10,
     y: 20

    In worker javascripts:
    onmessage = function(event) {
      var data =;
      postMessage(data.x + data.y);
    Firefox  Alert: "Got: 30"
    Chromium Alert: "Got: NaN"

(2) In HTML:
    var args = [10, 20];

    In worker javascripts:
    onmessage = function(event) {
      var data =;
      postMessage(data[0] + data[1]);
    Firefox  Alert: "Got: 30"
    Chromium Alert: "Got: 10"

(3) In HTML:
    var args = [10, 20];

    In worker javascripts:
    onmessage = function(event) {
      var data =;
      postMessage(parseInt(data[0]) + parseInt(data[1]));
    Firefox  Alert: "Got: 30"
    Chromium Alert: "Got:  1"

I am not sure how Chromium handle this issue? Maybe I did something wrong?
Comment 8 by, Mar 8 2010
Status: Untriaged
dimitri to triage :)
Dmitry, can you triage this?
Labels: -Mstone-5 Mstone-X
Status: ExternalDependency
Not implemented upstream and it's unclear when it will be implemented. No demand to
justify complexity at the moment.
Comment 11 by, Jun 11 2011
 Issue 50432  has been merged into this issue.
Comment 12 by, Jun 14 2011
Labels: Feature-Workers
 Issue 112428  has been merged into this issue.
Labels: WebKit-ID-22723
Project Member Comment 15 by, Feb 26 2013
Labels: -WebKit-ID-22723 WebKit-ID-22723-NEW

Project Member Comment 16 by, Mar 10 2013
Labels: -Area-WebKit -WebKit-WebApps Cr-Content-WebApps Cr-Content
Project Member Comment 17 by, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Comment 18 by, Apr 10 2013
Now that Blink is separate from WebKit, this bug should be able to move forward. Correct?
Status: Available
Bulk status change for WebKit-ID-? bugs with ExternalDependency. These are now all Available. Feel free to return the status if the dependency is not on a WebKit contributor, but some other third party.
Comment 20 Deleted
Duplicate  issue 386691  is logged. I will check this, if no one else is checking it.
Comment 22 by, Jul 22 2014
What about being able to use offscreen WebGL API?
 Issue 386691  has been merged into this issue.
Comment 25 by, Oct 21 2014
Anyone working on it?
Not currently. Lifecycle issues get a little hairy once you start launching shared workers from other shared workers as you end up having to manage non-empty document sets (, and it's not clear that the added complexity is worth it when typically you can address the same use cases via MessagePorts + proxying worker creation via the parent document.
Comment 27 by, Oct 22 2014
Labels: Cr-Blink-Workers
According to the UseCounters, 92% of the Workers are normal workers and only 8% of them are Shared Workers (normal = 0.5594 [1], shared = 0.0483 [2]). If difficulty of implementation for shared workers is an issue, then this feature could be restricted to non-shared workers to make an implementation more feasible. Considering the fact that you're the first on this bug to mention shared workers, I think that most are happy with a functional solution for non-shared workers.

I mention SharedWorkers, as that's really the only case (creating a worker from a shared worker) that can't easily be addressed by proxying worker creation to the parent document (since SharedWorkers don't have a single parent document).

Point taken that we could simplify the implementation by only handling nested dedicated workers created from dedicated workers, but that's the less interesting case since it's trivially addressed via a polyfill.
BTW, if there are use cases that can't be addressed by proxying worker creation back to the parent document, please outline them here as that would be useful in determining the priority of this work.
Proxying worker creation to a document is not something I'd ever do because it's incredibly brittle.

The application (SharedWorker) posts some data to be gzipped by the entangled Worker, but the user closes that tab, because they didn't know it was THE MAGIC TAB.
Since there's no disconnect event, some flaky timeout or polling eventually discovers the Worker went away. The application chooses the next oldest tab, and requests that it create a new Worker, then resubmits the workload.

There is no viable workaround for Chrome except just doing the work in the SharedWorker.
If it doesn't support sub-workers then it doesn't support them.
Re: #31 - we are in agreement, that proxying from a SharedWorker is hard to do since any individual parent document can go away, which is my point in comment #28 that SharedWorkers are the main motivation to build explicit nested worker support (harder to justify building support only for the simpler case of dedicated workers because in that case you have a guaranteed parent document and proxying becomes much more feasible).
Another workaround is each parent of the SharedWorker has code capable of spawning new workers. So they have distributed capability if one node fails, others can still spawn new workers. 
Comment 34 by, Jun 26 2015
Labels: -Cr-Blink
Comment 35 by, Jul 15 2015
Labels: -Cr-Content-WebApps
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

Your comment REALLY got my hopes up.
If anyone is struggling with this issue, you might be interested in the simple pollyfill I've created. You can find it at
Note the suggested workaround of creating workers from the main thread and communicating via MessagePort is impeded by  issue 334408 , which prevents efficient transfers of ArrayBuffer.
Is anyone working on this? It is supported in Firefox 3.5, Opera 11.60 and IE 10...
I've been watching this thread for a while and it appears that the answer
is to your question is no.
Comment 42 by, Feb 29 2016
this is very unfortunate and I hope it gets addressed at some point. my app cannot use shared workers. it's passing large chunks of (cloned then zerocopy'd) data around for slicing. performance is good between document/workers and workers/workers.  parallelization is, therefore, only possible if a worker can spawn another set of workers.  going back through the parent creates untenable overhead and greatly complicates the code.
As noted before, the workaround is not a viable one for us since we need to transfer large amount of data and MessagePorts are currently not capable of doing a no-copy transfer of ArrayBuffer objects ( issue 344814 ). Proxying all communication through the main window is also complex to implement with possible performance issues (I haven't validated this but it feels like the main UI thread would become a bottleneck)
There is also the problem that the work around (list time I tried) doesn't
work in Firefox. Oddly enough both ways work in Edge and IE.

On Thu, Apr 7, 2016 at 12:39 PM, via
Monorail <> wrote:
Comment 45 by, Aug 31 2016 workaround doesn't work in Chrome Apps
Labels: -Hotlist-Recharge -mstone-X OS-All
Owner: ----
Status: Untriaged
What's the status here? This is important for allowing a ServiceWorker to do something expensive but not block the processing of network requests. For example if you wanted to transcode images, or if you wanted to transpile some other language into JS. Having to proxy through postMessage to a tab, then down into a SW is a very strange way to offload work from the SW, and might require extra round trips through the browser process of large data objects.

Also this bug is now over 6 years old, if we're not going to fix this we should have the spec changed to say this isn't actually supported by the web. Having MDN and the specs be wrong for 6+ years about what's possible on the web is bad for predictability, compat, and ergonomics.

Also note Firefox and Edge both support this (and have for many years), Safari and Chrome don't.

We need to make a decision here. :)
I don't remember if it was this thread or another but they basically said
'nofix' due to having to rip up a huge swath of their... something-or-other
code. I, too would like this to function according to spec as there are a
number of neat things that could be done, but alas.
Labels: -Pri-2 Pri-3
Status: Available
This issue doesn’t immediately apply to service workers. The spec does not yet support service workers creating shared workers or dedicated workers. See and

In terms of priorities, we likely won’t get to this task except as part of adding support for service workers, after those spec issues are decided.

WontFix’ing this and changing the spec seems extreme since Firefox and Edge implement it (unless they are eager to remove support). Note that there are larger compat issues in the ecosystem: Safari and Android Chrome don't support shared workers at all (issue 154571).

nhiroki@ may be able to comment on what would be required to support this.
Blockedon: 692909
Labels: WorkerPainPoint
Comment 52 by, May 31 2017
It looks like is seeing active discussion/work, so this bug is making progress. @nhiroki or @domenic, can you provide a NextAction date on this bug of when it would be a good time to check back in on the status of discussions here?
Comment 53 by, May 31 2017
somehow accidentally removed falken - adding back in!
Comment 54 by, May 31 2017
one last try to get the cc's right. sorry everyone!
I have to decompress multiple streams of compressed data, if I can do this in parallel instead of serial that would make a huge difference, but that needs nested workers...
I try to spawn a sub-worker to compute something in worker, but got an error: ReferenceError: Worker is not defined.
The bug seem alive 7 years ago, has any plan to fix it?
Please be serious enough, or decent enough to take this bug really seriously, we are trying to make kickass apps on your platform but are struggling because of this amateur behavior of yours chromium!

7 years for something that important is immature, come on, admit it!

In my opinion you have just given up on the project.
Welcome to the party. This has been a continuous nofix that has stopped me,
for years, from making a library to make multi-threading easy.

Now with cryptocurrency and whatnot, this NEEDS to be fixed ASAP.
Comment #58 doesn't make any sense.  Worker creation requests just need to be proxied to the main JavaScript context.  Multi-threading wouldn't have been possible before SharedArrayBuffers, which only shipped this spring.

There is literally a polyfill to emulate nested workers Today in Chromium:

I'm all for having this bug eventually fixed, but having written worker-heavy code this isn't a blocker and certainly doesn't mean Google has "given up" on Chromium.
Thank you for this. I was unaware.
Please keep discussions respectful and constructive, as the box below the edit field says.

It's true this has been a bug for a long time and a bug people want to see fixed. We don't have a targeted milestone for a fix. There have been changes to the worker infrastructure recently that has nested workers more feasible but it's still not something that can be done immediately.

Also, as mentioned earlier in the thread, currently nested workers would only be very useful for shared workers. I would like to support shared workers on Android before investing more heavily in them. Additionally the service worker spec discussion is still ongoing.
The polyfill mentioned above is a nice effort... however, it does not speak to the reason one would spawn subworkers in the first place, which would be to offload the *messaging*.

If offloading work is the only problem, of course that could be done with multiple workers from the main thread (and sure, the "polyfill" could be a good way to coordinate those workers- but it is not really a polyfill for subworkers from this perspective, it's simply a neat library for communication from the main thread).

There are numerous other types of problems that do rely on offloading the messaging between workers, where that itself is a sort of bottleneck, and for those situations proper subworkers are needed.
I haven't looked at the specific polyfill, but does seem like you only should need to circle back to the main context to create workers - messaging can go directly between workers via MessageChannel/MessagePort?
Sign in to add a comment