Javascript Debugging With Black Box

By Rickard Dahlstrom | Posted May 13, 2015 | 4 min. (685 words)

At the end of 2013 Firefox launched a tool called Black Box to their browser inspector. About a year later, Chrome did the same. If you don’t know about black boxing scripts but you need to carry out Javascript debugging in your code, you should definitely give this post a read.

What is Black boxing?

Black boxing allows you to disable scripts for debugging, so you can focus on debugging the scripts that are relevant. E.g you are debugging Javascript a Backbone/Marionette app which is using underscore and jquery under the hood. Most likely you have a bunch of other favorite plugins/libraries/frameworks. When we debug, we most likely don’t want to debug all those vendor scripts. Most of the time we just want to debug our own scripts or maybe just some of them. And this is when black box comes in handy. We can black list all scripts that are not relevant for this debugging case.

How would we normally do it?

We would click through the code with the buttons

step over next function call
step in to next function call
step out this function call

That works fine, but…

Every time we click we have to think. “Should I click step-in-to or step-over?” The same question could in many cases be – “Is this a vendor function or is it a function I wrote?”

Next line. We have to ask the same question again. So if you’re stepping through 10 lines, you have to chose between step-over or step-in-to 10 times. If you do this debugging procedure 10 times you have to ask the question 100 times. I guess you see what we’re getting at. It’s a minor thing that you have to do very often. How annoying.

With black box we can make this decision beforehand. What scripts are not relevant for this debugging? Black box them and you don’t need to worry about stepping in to irrelevant functions. A common usage would be to black list vendor scripts for instance jquery, backbone, marionette and underscore.

Let’s make an example

The following example will demonstrate the difference of debugging with and without black box.

On click of the body element, we’re fetching two elements from the DOM. One of them is undefined. We pass the elements to the function foo, and then we calculate the length on them. Since one element is undefined on line 11 it will cause an error. This is the bug we want to hunt down as quickly as possible.

<body>

<div class="element"></div>

<script src="https://code.jquery.com/jquery-2.1.4.min.js" type="text/javascript"></script>

<script>

	var foo = function( element, undefElement ){		
		element.get(0).length;
		undefElement.get(0).length;
	};

	$('body').click( function() {
		debugger;
		var element = $('.element');
		var undefElement = $('.undefined');
		foo( element, undefElement );
	});

</script>

</body>

Since I don’t want to debug inside jQuery I will black list it. Now the the step-in-to button becomes something I would like to call step-in-to-if-relevant. In this case I can use step-in-to all the time without the worry of ending up in jquery scripts. Even though I click step-in-to, the debugger will do step-over on line 16,17 and 10,11 since they are jQuery functions.

How do I use it?

Chrome

– Alt 1. Go to source in the inspector. Right click the file you want to black list and choose black box script.

– Alt 2. Click on the cog to open up the settings view. Click the button “manage framework black boxing”. In the new pop up you can write a regexp as a path. This is great if you for example want to black box the entire vendor folder.

Firefox

Go to the debugger tab in the inspector. Mark the script you want to black list. Click on the eye in the very bottom left corner.

Conclusion

This feature makes it much easier to keep your debugging in the right scope. I hope you found this article useful and it saves you some time! Want to get notified of your Javascript errors in real-time when users run into them. Try Raygun free today, or book a demo with a friendly team member.