HTML and CSS Reference
In-Depth Information
It's great that Chrome and Safari have debugging tools, but what
if you want to debug in Firefox, too? You'll need to create your
own system for posting debug messages. However, as with all
communications from your worker—be it a debug message or
results from a worker's delegated tasks—you'll need to have some
agreed language between your workers and your main document
to differentiate between each of those different message types,
and this will depend entirely on your application. For instance,
you could prefix debug messages with the keyword “log:”
var xhr = new XHR('/someurl');
xhr.oncomplete = function (data) {
log('data contains ' + data.length + ' items');
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
prefixes in messages and actioning them:
var worker = new Worker('xhr_thang.js');
worker.onmessage = function (event) {
var data =' '),
action = data.shift(), // grab the first word
msg = data.join(' '); // put the message back
¬ together
if (action == 'log') {
} else {
// some other action
In this example, my agreed grammar is that all messages are
prefixed with an action. This could be log, set, run, or some
other action. What's important is that I now have a way to
inspect data that's inside the worker by sending data to my
log function when I'm not testing in Safari or Chrome.
NoTE It's possible for a
worker to get aborted or
terminated through a method
unknown to your code. If your
worker is being killed off by the
browser for some reason, then
the worker.onerror event is
going to fire. If you're closing
the worker manually, you're hav-
ing to do this from within the
worker via .close() so you
have the opportunity to notify
the connected documents that
your worker is closing.
Search WWH ::

Custom Search