How to debug web workers

I work with web workers in HTML 5 and look for ways to debug them. Ideally, something like firebug or chrome debuggers. Anyone have a good solution. without access to the console or DOM, which makes it difficult to debug iffy code

+49
javascript html5 google-chrome firebug
Feb 24 '10 at 4:59
source share
10 answers

As a quick fix on the missing console.log, you can simply use throw JSON.stringify({data:data})

+21
Feb 13 '11 at 17:47
source share

The Dev Channel version of Chrome supports worker debugging by introducing a fake worker implementation that mimics workers using an iframe on a work client page. You will need to go to the "Scripts" panel and check the "Debug" box on the side panel "Workers" on the right, and then reload the page. Then the working script will appear in the list of page scripts. This simulation has certain limitations, although since the working script will be launched in the client page thread, any lengthy operations in the working mode will freeze the browser user interface.

+53
Apr 28 '10 at 15:00
source share

in the chrome debugger, on the script tab, select the working panel and select a pause at startup. This will allow you to debug the worker and insert breakpoints .. but you do it all in another window

+11
Apr 08 2018-12-12T00:
source share

WebWorker can be debugged like a regular web page. Chrome provides debugging tools for WebWorkers in chrome: // inspect / # workers .

Find the web artist you want and click check. A separate developer window opens dedicated to this web tool. The official [instructions] [2] merit verification.

+11
Oct 22 '14 at 11:48
source share

Like Chrome v35

  • Upload your page and open the Chrome Developer Tools.

  • Click the Sources tab.

  • Check Check Pause of Start as shown below:

    Debugging workers in Chrome Dev Tools

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

Edit: in newer versions of Chrome (I use v39), workers are on the Themes tab, instead of having their own Workers tab (Themes tab will become visible if there are working workers).

+10
Jun 13 '14 at 6:04
source share

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

+2
Apr 23 '14 at 5:55
source share

The accepted answer is not really a solution for everyone.

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

and if you are in Chrome, you can debug web workers the same way you debug regular scripts, the .log console will print to your tab if you do. But if your worker is generic, you can take a look at chrome://inspect .

Extra tip. Since it is difficult for difficult people to master new users for javascript, I wrote an extremely lightweight shell for them that provides you with a consistent API for both types of workers. It is called Worker-Exchange .

+1
Jan 07 '15 at 13:04 on
source share

Next to JSON.stringify () there is also port.postMessage( (new Object({o: object})) ) . Perhaps using it in tandem with JSON.stringify would be more useful.

Hope this was helpful!

0
Jul 18 '13 at 5:02
source share

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

The WebStorm JavaScript debugger can now hit breakpoints inside these background workers. You can go through the frames and explore the variables just as you used. In the drop-down list on the left, you can move between workflows and the main application thread.

Web Artist Debugging Screenshot </ a

0
Feb 16 '16 at 19:33
source share

A simple solution for accessing messages / data from a worker for debugging purposes is to use postMessage() from your workflow to pass the required debugging information.

These messages can then be "caught" in the handler of the parent onmessage process, which can, for example, log messages / data transferred from the worker to the console. This has the advantage of being a non-blocking approach and allowing workflows to work like real threads and debug in a normal browser environment. While this solution does not include checking the workflow level of the workflow at the breakpoint level, in many situations it provides the ability to display as much or as little data from the workflow as possible to aid in debugging.

A simple implementation might look like this (corresponding excerpts):

// Somewhere in the working onmessage working onmessage (use as often as possible):

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

// In the parent 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... } }; 
0
Sep 16 '16 at 8:46
source share



All Articles