blog · git · desktop · images · contact & privacy · gopher


Ausflüge ins WebKitGTK+- und XUL-Land

Es gibt keinen einfachen Browser. So ein Ding nur für Nerds und Hippies. Ein Browser, der einfach nur Webseiten anzeigt und nicht noch tausend andere Sachen macht. Ein Browser, dessen Code so kurz ist, dass man ihn tatsächlich lesen, verstehen und verändern kann … Hach, das wäre schön.

Ja, klar, surf ist schon ziemlich dicht dran. War aber auch nicht so ganz das Richtige für mich, ich hätte einige Sachen ändern wollen. luakit hatte ich früher einige Zeit lang benutzt, dann dwb, beide auch deutlich zu dick. Damals waren die aber trotzdem ganz solide. Ich habe dann halt doch wieder lange Zeit Firefox benutzt, bis mir letzte Woche der Geduldsfaden riss. Ich will etwas Einfacheres haben.

Im Hinterkopf hatte ich, dass die genannten Browser alle WebKitGTK+ verwenden, also geschah am Wochenende das Unvermeidliche: lariza, eine Eigenentwicklung, ein wirklich ganz einfacher WebKitGTK+-Browser, der nur das können soll, was ich will und brauche. Möglichst wenig Code. Vermutlich wird dieser Browser für niemand anderen auf diesem Planeten sinnvoll sein, aber es ist auch nicht meine Absicht, das Volk glücklich zu machen. Ich möchte mein ganz persönliches Browser-Problem lösen.

– Nachtrag 2014-06-21: Hmmm, eigentlich hat surf durchaus das „Nerd-Hippie-Zertifikat“ verdient und mein Opener ist falsch. Ich glaube, mein Problem mit surf war eher, dass er nicht so funktioniert, wie ich mir das vorstelle. Aber das ist ja kein Problem und auch gar nicht der Knackpunkt. Ich hätte auch surf nehmen und modifizieren können. Naja, egal, jetzt habe ich bei Null angefangen, was einen größeren Lerneffekt hatte.

Das ganze Wochenende habe ich eigentlich nur mit Hacken verbracht und ich hatte lange nicht mehr so einen Spaß. Alles hat prima funktioniert und ich hatte dann gestern Abend einen guten, funktionierenden Prototypen. Noch war nicht alles drin, was ich haben wollte, aber es sah alles sehr vielversprechend aus und eigentlich fehlten nur noch Kleinigkeiten. Zufrieden wie ich war, habe ich das Projekt auf GitHub publiziert.

Fünf Minuten nach dem „git push …“. Hmm, abgestürzt. Wieso denn das? Ein Segfault in libpixman. Kurz rumgesucht und entsprechende Bugreports von 2010 gefunden, die mein Problem beschreiben. Hmm. Okay, erstmal einen Workaround einbauen.

30 Minuten später. Abgestürzt. Was ist denn da los? Naja, es ist Sonntag Abend und auch damals ist luakit einmal im Monat abgestürzt oder so. Auch Firefox segnet manchmal das Zeitliche, wenn auch wirklich sehr selten. Vermutlich nicht weiter tragisch.

Heute auf der Arbeit habe ich dann fast ausschließlich lariza benutzt – bis auf die paar Momente, wo mir noch ein, zwei Features gefehlt haben. Fast bis zum Feierabend hatte ich nicht einen einzigen Absturz – und dann ganz kurz vor Schluss direkt zwei Stück in kurzer Zeit.

Weiter im Netz gesucht und einen Bugreport bei dwb gefunden, der ein ähnliches Problem beschreibt. In diesem Bugreport ist auch eine Webseite verlinkt, die dwb crashen soll. Ausprobiert: dwb crasht. In meinem Browser probiert: Jawohl, crasht. In luakit: Crash. In surf: Crash. Hmm… Ist das ein Arch-Problem? Ubuntu-VM aufgezogen, meinen Code kompiliert, Ergebnis: Crash. In surf unter Ubuntu probiert: Crash. Da lariza sehr klein ist, konnte ich es leicht testen: Auch die Variante „GTK+ 3 und WebKit2GTK+“ statt dem eigentlich sinnvollen „GTK+ 2 und WebKitGTK+“ (sonst geht Flash nicht) stürzt bei genau denselben Webseiten ab. Midori crasht auch. Ugh.

Besser wird’s dadurch, dass der „echte“ WebKit-Browser Safari in einem aktuellen MacOS X nicht abstürzt, irgendwie auch nicht.

Im Arch-Forum gestöbert. Mehrere Threads gefunden, in denen sich Leute über WebKitGTK+-Crashes beklagen.

So langsam dämmert mir jetzt, dass es um WebKitGTK+ derzeit überhaupt gar nicht gut bestellt ist. Zu meinen luakit-Zeiten war das noch anders und auf die Qualität von damals hatte ich mich verlassen, als ich anfing zu programmieren. Hätte ich vorher mal noch ein paar Tage lang dwb benutzt, wäre es mir vielleicht früher aufgefallen. Das ist extrem schade und frustrierend. Eigentlich ist WebKitGTK+ nämlich eine richtig tolle Sache und außerdem verdammt schnell. Ich würde das sehr, sehr gerne verwenden und meine lariza zuende bauen. Aber bei diesen vielen Abstürzen wird mir da etwas mulmig.

Vorhin habe ich mir dann noch kurz Mozillas XULRunner angeschaut. Zuerst war ich davon auch sehr angetan, bis ich einen minimalen „Browser“ (ein Fenster, das eine Webseite anzeigt) mal auf meinem Netbook gestartet hatte. Ergebnis: Eine minimale XUL-Anwendung ist genauso langsam wie der echte Firefox. Heilig’s Blechle! Was für ein Showstopper. Okay, möglicherweise war meine Annahme etwas naiv, dass Firefox der langsame Teil sei und nicht sein Unterbau. Vielleicht kann man XUL trotzdem mal im Hinterkopf behalten. Was den Spaß aber auch trübt, ist, dass ich alles in JavaScript schreiben muss und gar keinen richtigen Zugriff auf das System habe. Ich bin halt mehr so ein C-Mensch.

Tja und jetzt? Ich habe zwei Möglichkeiten: Weiterhin Firefox verwenden oder an WebKitGTK+-Patches arbeiten. Eigentlich war meine Intention ja, dass ich den Aufwand, der durch Firefox entsteht, reduzieren möchte. Wenn ich jetzt anfange, WebKitGTK+ patchen zu wollen, dann muss ich mir die Frage gefallen lassen, ob ich denn nicht mein Ziel verfehlt habe. Auf der anderen Seite ist ein maßgeschneiderter Browser natürlich extrem reizvoll und diesen Aufwand vielleicht wert. Außerdem wäre es der richtige Weg, mich um einen Patch zu bemühen. Ich bin trotzdem unschlüssig.

Meh.