HTML and CSS Reference
In-Depth Information
tip Chrome recently
added a way to allow you
to debug workers from the script
tab in their Web Inspector, but
what it's really doing is running
the worker scripts through
iframes; this does mean the con-
sole.log lines actually appear in
the console. Very useful for
debugging a closed black box!
Since now, with a Web Worker, you're working in a sandboxed
environment, there is no access to the console debuggers. There's
no native way to do console.log(“who's the daddy?” ) in a worker.
To compound this hurdle, there's not even an alert box we can use.
To d e b u g a We b Wo r k e r, y o u m a y h a v e t o m a k e u p y o u r o w n
debugging methods.
Since you can move messages back and forth to the parent
document, you can create some system for posting messages
that should be sent to the console log. However with that, you
need to create a system that doesn't just process strings, you
need to have some agreed language between your workers
and your main document, and this will depend entirely on your
application. For instance, you could prefix debug messages with
the keyword “log:”
importScripts('xhr.js');
var xhr = new XHR('/someurl');
xhr.oncomplete = function (data) {
log('data contains ' + data.length + ' items');
};
xhr.send();
function log(msg) {
postMessage('log ' + msg);
}
Note that xhr.js is my made-up XMLHttpRequest script that returns
me some JSON data—you'll have to make your own!
In the main page in the onmessage event, I'll be looking for pre-
fixes in messages and actioning them:
var worker = new Worker('xhr_thang.js');
worker.onmessage = function (event) {
var data = event.data.split(' '),
action = data.shift(), // grab the first word
msg = data.join(' '); // put the message back together
if (action == 'log') {
console.log(msg);
} else {
// some other action
}
};
Search WWH ::




Custom Search