How to debug web workers

Question

I have been working with web workers in HTML 5 and am looking for ways to debug them. Ideally something like the firebug or chrome debuggers. Does anyone have any good solution to this. with no access to the console or DOM its kind of hard to debug iffy code

Cuspidation

Have you tried adding debugger; before the line you'd like to breakpoint? – Evetta

Um, the whole point is that firebug and web tools can't access the worker – Cuspidation

Um... Chrome's Web Inspector has a tab labeled 'Scripts'; under that, there is a panel inside an accordion labeled 'Worker Inspectors', with a checkbox labeled 'Debug'. I'm not sure if it works, but it's worth a try, did you? Or you're a 100% that it won't work? – Evetta

Last I checked it simulated a worker using an iframe. But it has been a while so it is possible that they have improved things – Cuspidation

@JuanMendes, Where? screenshot. Does this work for sharedworkers? – Probe

@Probe It's changed since the comment, try navigating to chrome://inspect/#workers – Evetta

I should hope things have gotten better over the last 7 years! – Cuspidation

Answer 1

As a fast solution on the missing console.log, you can just use throw JSON.stringify({data:data})

Bourgeoisie

Of course, this will halt execution where you do the debugging because of the throw. – Fidgety

See also werker.onerror and associated. It makes it pretty easy to get tracebacks at least. – Jeneejenei

Answer 2

Dev Channel version of Chrome supports debugging of workers by injecting fake workers implementation that simulates workers using an iframe within worker's client page. You will need to navigate to Scripts pane and tick Debug checkbox on Workers sidebar on the right, then reload the page. The worker script will then appear in the list of page scripts. This simulation has certain limitations, though -- since worker script will run in the client page thread, any long-running operations in worker will freeze the browser UI.

Valence

Chrome 17 was the first version to support web Worker debugging. – Crawly

Going to chrome://inspect seems to be the best option. It allows you to open a console for the runtime of the shared worker. – Fennelflower

@AlecHewitt How do you do that? I cannot find any shared workers listed there. – Lutetium

Firefox͏͏?? – Probe

Answer 3

The WebWorker can be debug just like a normal webpage. Chrome provides debugging dev-tools for WebWorkers at: chrome://inspect/#workers

Locate the desired running webworker and click "inspect". A separate dev-tool window will open dedicated to that webworker. The official instructions is worth checking.

Sy

It be a good idea to explain your answer more otherwise you've little chance of it being useful or accepted. – Pharyngeal

Thanks James. Elaborated – Sy

Web workers were not where the above answers say for me, but this worked thanks – Podophyllin

Now chrome://inspect/#workers shows only SharedWorkers, not Dedicated Workers – Leffler

Answer 4

Starting with Chrome 65, you can now simply use the "step-in" function of the debugger:

For more details, see their release note.

Wotan

It is not working on chrome 83.0.4103.116. I hit step-in (F11) many times . it just stays on the caller / postMessage but does not enter into the callee / worker code – Subglacial

This does actually work if the caller function is async (Note the screenshot/video does not shown it as async ..) . Otherwise it does not – Subglacial

Answer 5

As in Chrome v35

• Load your page and open Chrome Developer Tools.
  
  

• Navigate to Sources tab.
  
  

• Check Pause on Start check-box, as shown below:
  
  

• Reload the page, the debugger will pause in the web worker, though in a new window!

Edit: in newer versions of Chrome (I'm using v39), the workers are under a "Threads" tab instead of having their own "Workers" tab (The Threads tab will become visible if there are any running workers).

Obedient

unable to find it on chrome 38 ubuntu – Carabao

Unable to find it too. There isn't even a subpanel titled "Workers". – Probe

Firefox͏͏?? – Probe

Answer 6

in the chrome debugger, in the script tab, scroll to the worker panel, and select pause on start.. it will allow you to debug a worker, and insert break points.. but you do all that in a different window

Jameson

Firefox͏͏?? – Probe

Answer 7

You can use self.console.log('your debugging message')

Besse

Answer 8

On new versions of Google Chrome just go to Deveverloper Tools > Sources (Or Right click menu > Inspect > Sources).

At the bottom of the Page left panel list you'll see the services workers within an engine icon.

Macrography

That doesn't actually let you set breakpoints or step through code though... – Cashbook

Answer 9

The accepted answer is not really a solution for everyone.

In that case you can use console.log or console.debug or console.error in Web Workers in Firefox. See Bug #620935 and Bug #1058644.

and If you are in Chrome, You can debug web workers just like you would debug normal scripts, the console.log will print to your tab if you do. But in case your worker is a shared one, you might want to have a look at chrome://inspect.

Extra Tip: Because Workers are quite difficult to learn for people new to javascript, I've wrote an extremely lightweight wrapper for them that provides you a consistent API across both type of workers. It's called Worker-Exchange.

Carabao

Very important: these logs won't go in the page log, BUT in the Browser Console (available with ctrl+shift+j or by clicking the web developer tools icon) – Azotic

@autra, thanks for reminding me about this answer, I just updated with the method of Chrome and mentioned Worker-Exchange. – Carabao

But you are still not explaining that in firefox, you should look to the Browser Console, not the regular console of the web developer tools. Btw, nice API! You may want to have a look at github.com/gaia-components/threads that does basically the same thing (among others), but also adds iframe support. – Azotic

Answer 10

A simple solution to gain access to messages/data from a worker for debugging purposes is to use postMessage() from within your worker thread to pass back the debugging information you want.

These messages may then be 'caught' in your parent process' onmessage handler, which could for instance log the messages/data passed back from the worker to the console. This has the advantage of being a non-blocking approach and allows for worker processes to run as real threads and to be debugged within the usual browser environment. While a solution like this doesn't enable breakpoint-level inspection of worker process code, for many situations, it offers the ability to expose as much or as little data as needed from within a worker process to aid in debugging.

A simple implementation may look like the following (relevant excerpts shown):

// Somewhere in the worker's onmessage function scope (use as often as needed):

postMessage({debug:{message:"This is a debug message"}});

// In the parent's onmessage handler:

myWorker.onmessage = function(event) {
   if(event.data && event.data.debug) {
      // handle debug message processing here...
      if(event.data.debug.message) {
         console.log("message from worker: %o", event.data.debug.message);
      }
   } else {
      // handle regular message processing here...
   }
};

Buettner

Answer 11

Beside JSON.stringify(), there's also port.postMessage( (new Object({o: object})) ). Maybe using it in tandem with JSON.stringify will be more helpful.

Hope this was helpful!

Pareu

Answer 12

In February 2016, WebStorm released support for debugging web workers.

WebStorm JavaScript debugger can now hit breakpoints inside these background workers. You can go through the frames and explore variables the same way as you’re used to. In the drop-down list on the left you can jump between the workers’ threads and the main application thread.

Pozsony

Answer 13

in workerpool npm you just use:

.catch(function (err) {
        console.error(err);
    });

Gwenny

This shows how to log an error but OP is asking about how to live debug – Pitiful

Answer 14

Navigate to chrome://serviceworker-internals/ and tick the box beneath Open DevTools window and pause JavaScript execution on Service Worker startup for debugging.:

Haemophilic