Wednesday, July 22, 2009

Google Chrome's Very Incomplete Web Worker Support

In bespin we use a facade that allows us running JavaScript code in Web Workers, Gears Workers and if those are not available in the main thread.

Google Chrome does not yet support Web Workers but since it has Google Gears built in it should use the appropriate fallback. Turns out it didn't with our original code.

I naively implemented object detection to check for the availability of the Worker-object like this:
if (typeof Worker == "undefined") {
For some reason the statement above is actually true in Chrome 2, even though as stated above support for the Worker API has not been implemented.

I then tried to instantiate the Worker object. All this does is to throw an exception with the message "Worker is not enabled". This looks like an unfinished implementation that was only partially removed or something in that direction.

This code handles the special case:
var noWorker = typeof Worker == "undefined" ? true : false;
if(!noWorker) {
try { new Worker("test.js") }
catch(e) {
e = e + ""
if(e.indexOf("Worker is not enabled") != -1) {
noWorker = true;
I'd be very interested why this fragment of the worker implementation was left in the code? Most likely it is a bug but it is questionable whether it will be fixed since the next version of Chrome will actually support the Worker API.


robertc said...

Is it because Worker is in Webkit, but they want to use Gears instead and they've done an incomplete job of commenting it out?

Masklinn said...

If the test is done only once, why not remove the initial test and just go for the try/catch based one? It should work all the time nay?

Worker is a JS API, WebKit is a layout engine (so HTML + CSS). Safari and Chrome have completely different JS engines (resp. Nitro, formerly known as Squirrelfish Extreme, and V8) so the JS part, including Worker I'd guess, would be independent.

Furthermore, it doesn't make sense for Chrome to include a completely broken Worker that merely has the advertisement part wrong, that wastes everybody's time.

Finally, while IE does Chrome doesn't have the mindshare to play that kind of tricks.

Alex Russell said...

Some questions:

* What channel does this bug occur on? Dev? Beta? Stable?
* Is it logged as a bug at If not, would you please file it?
* Are you running with non-default command-line switches (e.g., --enable-workers)?


Malte said...

@Masklinn: Indeed one could only use the try block, but we really want to remove that clutch eventually.

@Alex: This is the current windows release version. Nothing fancy. I'm happy to file a bug if this is not known.

Malte said...

OK, bug filed

Andrea Giammarchi said...

actually, there is a trick able to understand if the Worker is Buggy or not.

if(!Worker || Worker.prototype.constructor === Worker){
// ... gears fallback ...

also I do not get why you do not like the e.message property ... but this is another story.


Malte said...

As acknowedleg by Google this was an oversight in the last Chrome release that won't be fixed until 3.0

I don't really have a problem with the message. It was just unfortunate that the stub was left in at all.