Salt and Pepper — Running native code within the browser with Google Native Client

When the web started off in 1989 at CERN, it was just a collection of static HTML documents, the first browsers were little more than document viewers, and computing still happend largely on big servers connected to many thin-client workstations. Much has changed over the last 20 years. Computing has moved from a the server-terminal model to the personal computers we know, and as web browsers are rapidly transforming from document viewers into sandboxed Javascript runtime environments, something amazing is happening: computing is moving back to a client-server model, with servers located in the cloud serving web applications running in the browser sandbox.

With browsers transforming into target platforms for general application development, there comes a desire for software running at near-native speed, something which a highly dynamic language like Javascript still has a hard time to deliver (even though Javascript runtimes have improved speed tremendously over the last years). It is not surprising that Google has come up with their own answer to this problem: Google native client (NaCl) allows native C/C++ code to be compiled to run directly in the browser and has been part of Chrome since version 14 (November 2011). In this blog post, I’ll take a closer look at this technology and explore how it works. Weiterlesen

10.12. Lösungen für Debugging von Mobile Web Apps

Webkit Web Inspector (Remote)

Dass Firebug in JavaScript programmiert wurde dürfte den meisten bekannt sein. Das gleiche gilt für den WebInspector von WebKit, wie er in Safari oder Google Chrome zu finden ist. Es dürfte also nicht wundern, dass für mobile Geräte mit Weinre von Patrick Mueller bereits 2010 eine Portierung des WebInspectors geschaffen wurde, die über eine JS-Include auf der im Website-Header im Mobilen Browser Remote Debugging Funktionalität zur Verfügung stellt. Somit kann bequem über dem Desktop eine Mobile Webseite debugged werden. Weinre läuft heute als PhoneGap Projekt, ist sozusagen Standard und ist natürlich auf GitHub zu finden.

Das Ganze hat aber leider eben leider Grenzen, was Features wie Breakpoints, Backtraces und Profiling angeht, d.h. genau die nützlichen Features, die normalerweis unter dem “Script”-Tab im Debugger-Panel zu finden sind.

JavaScript Remote Debugging mit WebKit/Chrome

Der nächste konsequente Schritt war also, den Debugger direkt in den Browser Runtime zu heben und eine Remote API anzubieten bzw. eine Verbindung zu dem ohnehin schon existierenden V8 DebuggerProtocol zu schaffen, dass sich allerdings nur auf JavaScript Debugging beschränkt. Das Gesamtpaket nennt sich dann WebKit Remote Debugging Protocol. Währenddessen arbeitete Google auch am ChromeDevToolsProtocol was aber mittlerweile deprecated ist.

Seit Frühjahr diesen Jahres bietet nun WebKit sein Remote Debugging Feature an, welcher praktisch alle bekannten WebInspector Features unterstützt – dazu zählen:

  • JavaScript Console & JS Debugger
  • CSS Debugging & Live Änderungen
  • DOM Manipulation & Debugging – z.B. DOM Knoten auf Änderungen durch JS Events überwachen (DOM Mutation Events)
  • Netzwerk & Timeline – Verfolgung von Netzwerk-Aktivitäten auf der Seite (HTTP, WebSocket, Timings)
  • Resourcen – LocalStorage, ApplicationCache, Cookies

Das Feature kann bereits seit einigen Chrome Versionen getestet werden. Eine aktuelle Chrome Version bevorzugt kann eine Debugger-Instanz mit chrome --remote-debugging-port=9222 gestartet wird.

Sodann ist eine zweite Browserinstanz für den Remote Web Inspector nötig – diese muss jedoch Ihr eigenes Nutzerprofil verwenden, um Probleme zu vermeiden: chrome –user-data-dir=<existierendes Verzeichnis>

Mit Navigation auf http://localhost:9222 im zweiten Browserfenster findet sich nun eine Thumbnail-Übersicht der geöffneten Tabs des zu debuggenden Browsers. Ein weiterer Klick auf das ein Thumbnail lädt nun den Debugger auf die komplette Seite, mit dem wie gewohnt gearbeitet werden kann.

Somit kann zusammenfassend folgendes zur Funktionsweise gesagt werden:

  • Der Web Inspector ist eine Web Application.
  • Der Debugger Server lieftert per HTTP HTML, JavaScript wie CSS aus.
  • Sobald die Application geladen ist wird ein WebSocket zu http://localhost:9222/json geöffnet
  • Der Debugging Port ist für jeden offen, insofern nicht durch Firewall geschützt.
  • Neue Remote Debugging Sessions ersetzen evtl. bereits laufende Debug-Sessions
  • Web Inspector Remote läuft derzeit nur in WebKit Browsern einwandfrei

In iPhone oder Android-WebKits sucht man den Debugger derzeit noch vergebens (about:debug), auch wenn es bereits einige ROMs für Android mit Web Inspector Support gibt. Blackberrys Playbook hingegen besitzt schon entsprechende WebKit Funktionalität.

Der Debugger bietet für den Browser eine vereinfachte, aber noch experimentelle JavaScript API, die z.B. auch durch Chrome Extensions angesprochen werden kann. Nach Google’s Vorstellungen sollen damit auch WebIDEs wie Cloud9 zum bereits integrierten JavaScript Debugger (lib-v8debug) einen vollwertigen “WebInspector” erhalten.

Google/Webkit sind nicht die ersten

Opera demonstrierte bereits 2008 mit DragonFly und Scope einen funktionierenden Remote Debugger, mit dem es möglich ist sich an an einen Opera Mobile oder auch Desktop Opera via TCP-Port ranzuhängen und nicht nur JavaScript zu debuggen. Nachteil an der ganzen Sache: Im Mobile Web dominiert derzeit WebKit.

Firebug Crossfire

Ein ähnliches Projekt existiert seit Anfang diesen Jahres mit Firebug Crossfire, was ähnliche Möglichkeiten bieten soll. Zudem unterstützen die JavaScript Development Tools (JSDT) für Eclipse bereits Crossfire. Derzeit befindet sich das Projekt jedoch noch in der Alpha-Phase, aber darf bereits getestet werden.

Weitere JavaScript Debugging Plugins

Für den, der nodejs debuggen muss, gibt es mit dem NodeInspector eine schicke Lösung, mit der es möglich ist, dies bequem im Browser zu erledigen. NodeInspector ist wie ebenfalls wie Weinre eine Adaption von WebInspector.

Für JavaScript Debugging in der IDE, d.h. bequem Breakpoints in den Quelldateien des geöffneten Projekts setzen, haben wir zum einen die ChromeDevTools als Eclipse-Plugin. Zum anderen hat IntelliJ mit IDEA 10.5 und PHPStorm 3 das V8 DebuggerProtocol bereits implementiert.

Eine weitere einfache JavaScript-Konsole stellt z.B. JSConsole bereit, dass zum Debuggen von iPhone oder Android-Mobile Apps benutzt werden kann.