On-device JavaScript Debugging: Intro

12. Oct, 2010

As I wrote in my previous post, a paradigm shift is going on in Web-App development. The understanding that Web-App development is as complex as native App development is slowly cementing in the minds of developers, managers and development software companies.

The logical consequence of this understanding is that Web-App developers require the same kind of support that their native counterparts do. This means powerful application frameworks, IDE integration, and tool support.

In the native dev world, on-device debugging has been available for a long time. Every native App developer knows that it is not sufficient to develop on a device emulator. Differences in capabilities, performance, hardware and memory availability make things difficult.

Let’s take a look at what the web-app world has to offer. In this introductory post I will focus on the low level protocols/tools that either are available today or will be available soon. I will get into details of setting up and actually doing on-device debugging in a later post.

Google V8 debugger protocol

V8 is Google’s open source JavaScript engine. It has support for debugging the JavaScript code running in it. From the V8 wiki:

There are two API’s for this a function based API using JavaScript objects and a message based API using a JSON based protocol. The function based API can be used by an in-process debugger agent, whereas the message based API can be used out of process as well.

Check Google V8 debugger protocol for more details.

Google Chrome Developer Tools Protocol

The main motivation behind this extended protocol was to be able to use TCP/IP sockets as a remote debugging transport. From my perspective this is where things start to get interesting. From the ChromeDevToolsProtocol wiki:

The existing V8 Debugger Protocol is not sufficient to provide Google Chrome, Chromium, or any other browser that supports the protocol, with the capability of remote debugging via TCP/IP sockets. The V8 Debugger protocol covers only JavaScript debugging operations, and only within a single V8 virtual machine (VM). In reality, there can be one or more separate V8 VMs inside a Google Chrome instance, residing in different renderer processes. Also, retrieving URLs loaded in the browser tabs, inspecting or modifying the DOM tree are not covered by JavaScript operations.

Check Google Chrome Dev Tools Protocol for more details.

But Google is not the only party seriously involved in mobile on-device debugging. Let’s see what others are doing:

Opera Scope Transfer Protocol

The fine folks at Opera have been supporting this for quite some time. All that is required is a copy of Opera Desktop 9.5 or higher (which includes the Dragonfly developer tools per default) and a device running Opera Mobile 9.7 or higher. Check Remote debugging with Opera Dragonfly for further details.

Opera’s protocol used for debugging is called Scope Transfer Protocol (STP/0) and is also open source. STP/1 is in the works and will be available soon.

Android Debug Bridge (ADB)

If you are into Android development (with Java) you probably know that adb is your friend. For the rest of you, adb is a command line tool that comes with the Android SDK and has a lot of nice functions to offer. A good overview is presented here: Android Debug Bridge.

Adb has an option to redirect the device’s debug log to the console. This log output contains the output of console.log(). So with just a bit of regex magic you can have your console.log() output on your local console.

iPhone Console Redirection

I am aware of two options for the iPhone. One is to use Joe Hewitt’s Firebug for iPhone, which contains a small web server that acts as a bridge between mobile Safari and Firebug. The other one is the Bugaboo App. This App basically displays a WebView and also has a built-in web server that you can access with your desktop browser to send JavaScript statements to it.

Summary and Outlook

All this looks very promising. But does this mean you can launch your favorite IDE, connect your device, hit “Debug” and you can start browsing the DOM, setting breakpoints and stepping through the code? The answer is: maybe. It depends on the device and the browser in question. Some browsers allow a full desktop-like debugging experience, others are limited to console redirection and yet others have to stick to the good old alert() debugger for the time being.

In follow-up articles I will get into details of how to accomplish several “levels” of remote on-device debugging on mobiles.

Categories: Mobile web technology

One Response to “On-device JavaScript Debugging: Intro”

Raju Bitter 08. Nov, 2010

On-device debugging will be one of the key features for JavaScript engines. For mobile widgets based on the W3C Widget standard, Opera enables remote debugging through Dragonfly. Debugging JavaScript based apps on mobile phones can be very complex, especially with the different JS APIs, versions, and standards for mobile widgets.

Palm/HP webOS 2.0 supports development of services running on the phone based on NodeJS (the V8 engine), and we an expect other mobile OS vendors to offer similar features, soon. For services it’s even more important to have support for remote debugging and memory profiling. We probably can’t expect one open standard for remote debugging of JS engines, supported by the major JS engine vendors/projects, but of course that would be better.