Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 150 users
Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 692909


Participants' hotlists:
test

Show other hotlists

Other hotlists containing this issue:
Top-Starred-Bugs


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

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

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 
defined".


 
fibonacci1.js
601 bytes View Download
Labels: -Area-Undefined Area-WebKit WebKit-WebApps
Comment 2 by karen@chromium.org, Jan 11 2010
Labels: Mstone-5 karenianreview
Labels: -karenianreview
Status: Assigned
Dave - any chance you can look at this?
Comment 4 by levin@chromium.org, 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):

https://bugs.webkit.org/show_bug.cgi?id=22723

https://bugs.webkit.org/show_bug.cgi?id=25212
https://bugs.webkit.org/show_bug.cgi?id=25215
https://bugs.webkit.org/show_bug.cgi?id=25255
https://bugs.webkit.org/show_bug.cgi?id=25270
https://bugs.webkit.org/show_bug.cgi?id=25273



Comment 5 by levin@chromium.org, 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 = event.data;          
  postMessage(n+10);
};

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
    }
    worker.postMessage(args);

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

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

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

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

    In worker javascripts:
    onmessage = function(event) {
      var data = event.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 karen@chromium.org, 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 levin@chromium.org, Jun 11 2011
Cc: chrome-d...@googlegroups.com
 Issue 50432  has been merged into this issue.
Comment 12 by levin@chromium.org, Jun 14 2011
Labels: Feature-Workers
 Issue 112428  has been merged into this issue.
Labels: WebKit-ID-22723
Project Member Comment 15 by bugdroid1@chromium.org, Feb 26 2013
Labels: -WebKit-ID-22723 WebKit-ID-22723-NEW
https://bugs.webkit.org/show_bug.cgi?id=22723

Project Member Comment 16 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-WebKit -WebKit-WebApps Cr-Content-WebApps Cr-Content
Project Member Comment 17 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Comment 18 by fer...@gmail.com, 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 dade...@gmail.com, Jul 22 2014
What about being able to use offscreen WebGL API?
Cc: nyerramilli@chromium.org
 Issue 386691  has been merged into this issue.
Cc: jochen@chromium.org
Comment 25 by joea...@gmail.com, 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 (http://www.w3.org/TR/workers/#the-worker-s-lifetime), 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 rob@robwu.nl, Oct 22 2014
Labels: Cr-Blink-Workers
#26
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.


 [1] https://www.chromestatus.com/metrics/feature/popularity#WorkerStart
 [2] https://www.chromestatus.com/metrics/feature/popularity#SharedWorkerStart
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 tkent@chromium.org, Jun 26 2015
Labels: -Cr-Blink
Comment 35 by tkent@chromium.org, 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!

-Anthony
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 https://github.com/dmihal/Subworkers
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 stew...@neuron.com, 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, mathieu.hofman.citrix@gmail.com via
Monorail <monorail@chromium.org> wrote:
Comment 45 by shlat...@gmail.com, Aug 31 2016
https://github.com/dmihal/Subworkers workaround doesn't work in Chrome Apps
Cc: hajimehoshi@chromium.org dim...@chromium.org rbyers@chromium.org yhirano@chromium.org
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. :)
Cc: kinuko@chromium.org falken@chromium.org kenjibaheux@chromium.org horo@chromium.org
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.
Cc: nhiroki@chromium.org
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 https://github.com/w3c/ServiceWorker/issues/678 and https://github.com/whatwg/html/issues/411

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
Cc: -falken@chromium.org domenic@chromium.org
It looks like https://github.com/whatwg/html/issues/411 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?
Cc: -jochen@chromium.org falken@chromium.org
somehow accidentally removed falken - adding back in!
Cc: jochen@chromium.org
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?
Thanks!
Sign in to add a comment