84

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

Zachary K
  • 3,205
  • 1
  • 29
  • 36
  • 1
    Have you tried adding `debugger;` before the line you'd like to breakpoint? – Ruan Mendes Nov 17 '11 at 16:27
  • Um, the whole point is that firebug and web tools can't access the worker – Zachary K Nov 17 '11 at 17:51
  • 13
    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? – Ruan Mendes Nov 17 '11 at 18:48
  • 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 – Zachary K Nov 19 '11 at 15:32
  • @JuanMendes, Where? screenshot. Does this work for sharedworkers? – Pacerier Sep 08 '17 at 19:59
  • @Pacerier It's changed since the comment, try navigating to chrome://inspect/#workers – Ruan Mendes Sep 08 '17 at 21:01
  • I should hope things have gotten better over the last 7 years! – Zachary K Sep 18 '17 at 07:49

14 Answers14

58

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.

caseq
  • 1,929
  • 1
  • 16
  • 9
30

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.

frzsombor
  • 2,274
  • 1
  • 22
  • 40
user2519809
  • 301
  • 3
  • 4
27

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

daralthus
  • 13,723
  • 2
  • 16
  • 13
21

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

enter image description here

For more details, see their release note.

Philipp Claßen
  • 41,306
  • 31
  • 146
  • 239
  • 1
    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 – WestCoastProjects Jul 09 '20 at 23:42
  • This does actually work *if the caller function is `async`* (Note the screenshot/video does *not* shown it as async ..) . Otherwise it does not – WestCoastProjects Jul 09 '20 at 23:48
12

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:

    Debugging workers in Chrome Dev Tools

  • 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).

akauppi
  • 17,018
  • 15
  • 95
  • 120
Ashwin Aggarwal
  • 649
  • 8
  • 21
11

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

zeacuss
  • 2,563
  • 2
  • 28
  • 32
9

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

Harshit Jain
  • 492
  • 3
  • 8
2

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.

Steel Brain
  • 4,321
  • 28
  • 38
  • 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) – autra May 07 '15 at 13:50
  • @autra, thanks for reminding me about this answer, I just updated with the method of Chrome and mentioned Worker-Exchange. – Steel Brain May 07 '15 at 17:12
  • 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 https://github.com/gaia-components/threads that does basically the same thing (among others), but also adds iframe support. – autra May 12 '15 at 10:11
2

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...
   }
};
bluebinary
  • 1,026
  • 14
  • 17
2

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.

Service workers on Chrome 87

I.G. Pascual
  • 5,818
  • 5
  • 42
  • 58
0

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!

Cody
  • 9,785
  • 4
  • 61
  • 46
0

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.

WebStorm web worker debugging screenshot

Dan Dascalescu
  • 143,271
  • 52
  • 317
  • 404
0

in workerpool npm you just use:

.catch(function (err) {
        console.error(err);
    });
jmp
  • 2,456
  • 3
  • 30
  • 47
0

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

Semnodime
  • 1,872
  • 1
  • 15
  • 24