Debugging JavaScript in a Hostile Environment

By E.J. Dyksen on 16 02 2014

We recently built the web front-end portion of a project using AngularJS. The requirements for the project specified that the app needed to run in a number of different environments, one of which was particularly hostile to complex JavaScript applications.

That hostile environment was a Visual Basic application using the WebBrowser Control to host HTML/JavaScript content. Business requirements dictated that the AngularJS application had to run properly in this environment.

The WebBrowser Control uses the system version of Internet Explorer as its rendering engine, so we thought testing our app in IE would suffice. However, when we started seeing different JavaScript behavior between the system version of IE and the WebBrowser control, we knew that "it works in IE" wouldn't be good enough.

The goals for our new approach were:

  • Enable print debugging in browsers with no console.
  • Allow quick, simple evaluation of JavaScript expressions.
  • Stupid simple to understand with no dependencies. We don't want to have to debug the debugger. We just want it to work.

Here's what we came up with. The code should be pretty easy to understand if you know JavaScript.

Putting this snippet at the end of an HTML document creates a div that is now your JavaScript console. Any calls to console.log will end up there. Also, a text box below the console allows you to evaluate JavaScript expressions on the page.

There is definitely room for improvement in this script. For example, though it would introduce a dependency, it wouldn't be too much work to add stack trace support using Stacktrace.js.

Sprinkling console.log everywhere isn't the most elegant form of debugging, but it was all that was available to us. We originally thought of this as a last resort for debugging, but ended up reaching for this little bit of code many times to solve tough problems.