Es sollte ein Bild per jQuery Funktion in ein Canvas geladen werden. Als Test dieser Quelle fragte ich den HEADER an, und bekam prompt eine Fehlermeldung in der JavaScript Konsole.

Access-Control-Allow-Origin

Unschwer zu erkennen was hier das Problem ist, zur Vermeidung von Cross Site Scripting darf man nur auf URLs der eigenen Domain zugreifen.

Nachdem Studieren dieser Mozilla Developer Seite war klar es ist durchaus möglich für ein Canvas Bilder zu laden. Aber das testen per HEAD ist eine weniger gute Idee, nun wird das Bild geladen oder nicht. Übertriebene Fehlermeldung verwirren die Anwender so wie so

Beschäftige mich seid ein paar Tagen mal wieder mit Greasemonkey, also mit JavaScript, und baue eine Script um das vorher alles mit “unsafeWindow” gelöst hat durch addEventListener. Ein Problem war das zum Teil viel HTML Code in die Seite geschrieben wird der aber wiederum Funktionen mit Parametern aufrufen sollte. Nach der Erkenntnis das man einfach nach dem einfügen in den DOM Baum die Objekte über die ID wieder Referenzieren kann, war eine for Schleife schnell geschrieben die jedem Element einen Listener verpassen sollte. Aber der Aufruf geschah dann immer ohne Parameter, egal wie ich versucht habe das zu lösen, die Allgemeine Lösung schien zu sein dem Objekt noch einen Parameter zu geben denn die Funktion wiederum auslesen sollte. Der naheliegende Weg, der mir aus Java bekannt war, einfach auf das Objekt zu schauen der den Event ausgelöst hat, gelang nicht auf den ersten Blick. Bis ich folgende Lösung im Netz gefunden habe, es lohnt sich sehr oft eine Nacht über dem Problem schalfen zu gehen.

for (var r=0;r document.getElementById(listName[r]).addEventListener("click", function(e){tooltiph(e)}, true);
}

Die gerufende Funktion greift dann wieder auf die ID zu die ja schon als eindeutiger Bezeichner aus einer Liste Stammt.

function tooltiph(e) {
var targ = e.target;
var name = targ.id;
var softInfo = GM_getValue(name);

Zur Erklärung: der Event wird mit dem (e) erst an die Pseudo Funktion dann an die zu Rufende Callback Funktion gereicht, beim ausführen schaut man auf den der es ausgelöst hat und greift dann auf das HTML Element zu. Nun steht die ID in einer Variable mit der ich arbeiten kann, das weiterreichen eines Wertes wird wohl etwas anders gelöst werden müssen.

Nach den Tagen der Aufregung über neue Browser wird es Zeit mal wieder einen anderen zu Testen, heute den Firefox in 3.1 Alpha 2. Über den Link bekommt man ihn auch schon als Portable Version zum ausprobieren unter Windows. Da leider in dieser Version die neue JavaScript Engine fehlt muss man auf die nightly builds zurück greifen.
Auf Golem findet man ein Video wie es aussieht wenn man OGG Videos direkt in den HTML Code einbettet. Der Bee-Industries Blog bietet gleich einen Test des Video Tags in HTML an, hier kann sich dann jeder überzeugen das seine Browser das nun unterstützt.

Ein Test meiner Seits mit der neuen JavaScript Engine und den Seiten auf denen ich viel JavaScript gebraucht habe wird später folgen nun erst mal Abendbrot

Die Meldungen nehmen kein ende, nun hat sich die Firma hinter dem TinyMCE dran gemacht und einen Vergleich der Browser gestartet. Habe ich eben auf der Infogurke gefunden. Hier gab es auch einen feinen Link zu einem Video der Firefox 3.1 Entwickler, die bekanntlich mit ihrem JIT Compiler mehr Geschwindigkeit erreichen, zumindest in dem Demovideo. Auch wenn es so erscheinen mag das man nur ein Sommerloch füllen möchte, für meinen Geschmack ist der Wirbel um die Browser richtig, und bringt den Markt ein wenig in Bewegung. Vielleicht erleben wir ja noch mal die Zeit in der es nicht mehr lohnt eine Sicherheits Lücke um IE aus nutzen zu wollen weil der Markt anteil zu gering ist.

Die letzten Tage hat Google die Welt der Browser ganz schön aufgewühlt, und das ist auch gut so. Die Bedenken der Gemeinde zum Thema Eula hat sich der Suchmaschinen Riese zu Herzen genommen und erst in den USA dann auch in Deutschland geändert. Golem liegt eine Bestätigung von Google Deutschland vor, das hier nachgebessert wird. Auch wenn ich es wichtig finde das man hier was tut interessiert mich die Technische Seite des ganzen deutlich mehr. Kurz bevor Chrome in mein Blickfeld geriet lass ich von der neuen JavaScript Engine die für den Firefox entwickelt wird, hier ist der Just in Time Compiler besonders Interessant. Leider muss der erst einmal aktiviert werden bevor mal von der höheren Geschwindigkeit profitieren kann. Im Gegenzug dazu bekommt diesen bei Googles “Chrome out of the Box”, was aber in beiden Fällen nicht wirklich schlimm ist.
Bei Chrome wird aber gerne behauptet das man das schnellste in Sachen JavaScript am Markt sei, diese Aussage will man bei Mozilla aber so nicht stehen lassen. Geht man davon aus das Chrome genau wie der Entwicklung Zweig von Firefox noch im Beta Stadium sind, legen sie was das angeht gleich auf.
Bei den Benchmarks wechseln sie sich dann aber schon ab, mal ist der eine mal der andere Schneller. Wie in diesem Artikel schon schön angemerkt wurde ist das Thema so neu das hier noch viel passieren wird.

Schnelle JavaScript-Engines dürften das Web als Plattform für komplexe Anwendungen einen entscheidenden Schritt voranbringen, unerheblich, ob sie TraceMonkey, Tamarin, SquirrelFish oder V8 heißen und ob die eine oder andere ein paar Prozent schneller ist.

Wollte an dieser Stelle eigentlich schreiben wie ich den neunen Browser von Google finde, aber leider gibt es dieser ja noch nicht für Linux. Also habe ich mir ein wenig die Videos angeschaut die von den neunen Funktionen schwärmen, nach Beendigung kam bei Heise aber schon eine Meldung hoch das der Google Browser mehr als eine Schwachstelle aufweißt. Es werden wohl mindestens alle sein die schon für das WebKit Engine bekannt sind.

Die Demo nutzt offenbar die in Safari respektive WebKit bekannte Carpet Bomb in Kombination mit einem Fehler in Java aus. Beim als “Safari Carpet Bomb” bezeichneten Verhalten legte Safari Dateien bei Downloads standardmäßig und ohne Rückfrage auf dem Desktop ab. Zusammen mit dem Internet Explorer, der DLLs im Unterschied zu anderen Anwendungen auch auf dem Desktop sucht, ergab sich daraus ein Sicherheitsproblem. Apple hat die Carpet Bomb in neueren Versionen von WebKit ab Safari 3.1.2 entschärft, allerdings greift Chrome noch auf die verwundbare Version 525.13 zurück, die in Safari 3.1 eingesetzt wurde. Für die finale Version setzt Google hoffentlich eine aktuelle Webkit-Version ein.

Auf Golem.de erfährt man derweil wie schnell der Browser im Vergleich zum Rest der Welt ist. Die Zahlen beeindrucken schon, aber Geschwindigkeit war, oder besser sollte heute nicht mehr, das Ausschlag gebende Argument für einen Browser sein. Nicht das wir uns hier falsch verstehen wenn der Aufbau einer Webseite spürbar länger dauert als einem anderen ist das schon ein Grund, nur für ein paar Millisekunden bis zu einer Sekunde steige ich nicht um. Der Browser soll mir die Funktionen bieten mit denen ich besser, effektiver und auch schneller Arbeiten (Browsen) kann. Bei Firefox mag ich halt die vielen AddOns die nicht gleich Bestandteil der Anwendung sind. Nur dann kann ich mir das aussuchen was für mich am besten passt, und das weg lassen was ich gar nicht brauche.

Das Google immer wieder für Überraschungen gut ist, ist bekanntlich nichts neues, aber seid langem habe ich nicht mehr so viele Artikel, Kommentare und Trackbacks zu einer Software gesehen. Jeder will mal Browsen mit dem neuen, wenige beschweren sich schon das es eh nicht taugt und der Überwiegende Teil lehnt sich zurück und greift in die Schale mit Fingerfood.

Im Promille Bereich wird sich die Anzahl der Menschen bewegen die hiermit etwas anfangen können. Damit sieht es schon deutlich besser aus.

Da musste ich heute morgen erst mal eine Putz Aktion an meinen Monitoren starten weil mein Kaffee im hohen Bogen auf den TFTs gelandet ist. Konnte es kaum glauben, das Google nun einen eigenen Browser auf den Markt bringt. Er basiert auf der WebKit Engine und einer komplett neu geschriebenen Java Script Engine die vom V8-Teams entwickelt wurde, näheres findet man hier. Interessant an der Engine ist der Just in Time Compiler:

Da die Geschwindigkeit von Webapplikationen in erster Linie von der JavaScript-Engine bestimmt wird, setzt Google hier auf eine komplett neue Lösung. Die vom V8-Team in Dänemark entwickelte virtuelle Maschine für JavaScript ist konsequent auf Multi-Core-Prozessoren ausgelegt. So sind die einzelnen Tabs des Browsers in unterschiedlichen Prozessen organisiert, sowohl in Bezug auf die Rendering-Engine als auch die JavaScript-Ausführung. Dies soll den Browser vor allem robuster machen, denn Fehler wirken sich nur auf ein Tab aus

Quelle Golem

Im Moment kann man den Browser noch nicht herunter laden, aber wenn es so weit ist wird der oder der Link der richtige sein, so munkelt man.
Ob der Browser genug neue Funktion mit bringt um einen Wechsel zu rechtfertigen wird wohl auch jeder für sich selber entscheiden müssen, es wäre aber nicht Google wenn hier einige Dinge ganz anders gemacht werden als im Rest der Browser Welt. Das erste Release erscheint natürlich für Windows, Mac und Linux Versionen werden später folgen.