Dies ist ein Gastbeitrag von Herrn Brenner. Die getätigten Aussagen reflektieren ausschliesslich die Meinung des Autors.

Lange Zeit war ich stolz darauf Firefox zu benutzen. Immerhin benutze ich ihn seit Version 1.0. Zugegeben war er da teilweise noch etwas buggy, doch die meisten Bugs wurden mit 1.5 ausgemerzt. Version 2.0 war dann perfekt. Es war ein Browser der das machte was man von ihm erwartet hatte. Für zusätzliche Features hatte er ein geniales Addon-System. Doch dann kam Firefox 3.0. Ich erinnere mich noch als ich frisch auf Firefox 3.0 geupgraded habe, mit meinem Notebook an einem Internetfreien Ort sass, an meiner Web-App rumschrauben wollte und mir Firefox plötzlich erzählen wollte dass ich nicht auf 127.0.0.1 zugreifen kann, weil Firefox im Offline-Modus ist. Danke Mozilla, nettes Feature.
Gut, das kann man deaktivieren, halb so wild. Doch so ging es weiter über die neueren Firefox-Versionen. Tab-Grouping was sich laggy anfühlt, nicht mit dem Rest zusammenspielt und wenn man intuitiv Escape drückt um das Ding weg zu bekommen, fragt Firefox einen ob man wirklich alle Tabs schliessen will. Als wäre das nicht schlimm genug, platzieren sie den Button da wo früher der Button für neue Tabs war. Danke Mozilla. Plötzlich steht http:// nicht mehr in der URL und Firefox scollt komisch. about:config hacken und smooth scrolling deaktivieren. Mit der nächsten Version wollen sie übrigens soetwas wie Firebug nativ einbauen. WIR HABEN DOCH SCHON FIREBUG!!1!

Firefox gibt einem zum Glück mit about:config und dem Addon-System extrem mächtige Werkzeuge an die Hand, sich von solchem Müll <insert less offending word here> zu befreien.

Aber wieso nicht einfach zu einem anderen Browser wechseln? Chrome, Opera, Internet Explorer? Weil die alle noch schlechter sind. Das Addon-System von Chrome ist schlecht. Opera hat keins. Alle anderen Browser kommen so oder so nicht in Frage.
Um den Chrome Fanboys zuvorzukommen, Chrome hat durchaus aufgestockt was sein Plugin-Interface angeht und bietet endlich API’s an mit denen sich LiveHTTPHeaders oder NoScript ähnliche Plugins realisieren lassen würden. Allerdings auch nur die Basisfunktionalität. Die Benutzeroberfläche selbst lässt sich nahezu gar nicht anpassen.

Dann gibt es da noch so Browser die vom Konzept her ganz nett sind. Beispielsweise uzbl oder luakit, diese bieten aber leider auch nicht genug API’s für ein anständiges NoScript oder LiveHTTPHeaders.

Wat do?

Ich habe mir also überlegt wie man einen Browser möglichst anpassungsfähig designen kann. Entstanden ist morgens um 3 Uhr ein POC (Proof of Concept) für einen neuen Browser.

Die Idee gab es schon, allerdings keine brauchbare Implementierung. Den Browser in HTML, CSS und JavaScript zu schreiben. Chromeless von Mozilla. Leider ist das Projekt inaktiv und die Gecko API’s nicht gerade was man unter Easy-to-Use versteht.
Chromeless führte einen neuen Tag ein, <browser> um das eigentliche Browserfenster im Interface zu rendern. Dies ist nötig da man leider nicht einfach ein iframe nehmen kann. Aus einem iframe könnte mit einem einfachen Javascript Framebreaker ausbrechen.

Ich habe mich entschieden QWebkit zu verwenden und ein Webkit über das ganze Fenster zu rendern. Darin wird ein interface.html gerendert. In dem interface.html können beliebige controls mit normalem HTML und Javascript eingefügt werden. Das Browserfenster wird über einen kleinen Hack (der jedoch erstaunlich gut funktioniert) angezeigt. Es wird ein normaler div-tag in der interface.html eingefügt und als Browser markiert. Über das DOM wird danach die exakte Position und Grösse des divs ausgelesen und ein kleines Python-Script rendert eine weiteres QWebkit an genau der Position.

Damit ist der Aufwand umgangen der Engine einen <browser-tag> beizubringen. Das interface.html hat jedoch noch keinerlei Kontrolle über den eigentlichen Browser. Doch auch hier hilft uns Qt. Mit der Methode addToJavaScriptWindowObject() können wir ein beliebiges QObject (das Super-Object von Qt) an Javascript exposen. Das interface.html kann nun also direkt das Browserobjekt kontrollieren indem es Python-Methoden aufruft.

Fertig ist das POC. Auf Python-Seite kann nun ein relativ dünner Wrapper geschrieben werden um das QWebkit, dieses an Javascript exposen und das interface.html kann den kompletten Browser per JavaScript kontrollieren

Die Vorteile sind meiner Meinung nach, dass jeder Webentwickler mit jQuery sein eigenen Browser schreiben kann.

Den Code werde ich noch etwas verbessern (dass der Browser wenigstens halbwegs brauchbar ist) und hier veröffentlichen.