Ich bin nicht der einzige, der sich in den letzten Wochen auf Twitter kritisch über billige IE-Witze geäußert hat. Schließlich scheint Microsoft ja mittlerweile begriffen zu haben, wie man einen Browser baut und die Internet Explorer 10 und 11 haben so viel HTML5 und CSS3 an Bord, dass man auf den ersten Blick vergleichsweise wenig zu meckern findet, gerade wenn man sie mit den diversen Mobile-Browsern vergleicht. Android-Standardbrowser und iOS-Safari sind was die fehlenden Features, zahllosen Bugs und Extravaganzen angeht nicht in einer Liga mit modernen Internet Explorern … jedenfalls quantitativ betrachtet. Was die „Qualität“ der einzelnen Probleme angeht fühlt man sich punktuell auch bei den IE mit zweistelliger Versionsnummer wie früher, zu glorreichen IE6-Zeiten …

Die Same-Origin-Policy (SOP) ist ein Sicherheitskonzept in Browsern, das den Zugriff auf Objekte wie z.B. Scripts nur dann erlaubt, wenn sie dem gleichen Speicherort entspringen. Als Ursprung bzw. Origin gilt die Kombination als Host, Protokoll und Port einer Web-Adresse; Ressourcen von http://foo.com kann http://www.bar.org nicht ohne weiteres verwenden – bei einem entsprechenden Versuch hagelt es Sicherheitsfehler (Details bei Wikipedia). In modernen Browsern lässt sich die SOP punktuell außer Kraft setzen um z.B. API-Verwendung über Domaingrenzen hinweg zu ermöglichen. Und manchmal sollten Browser die SOP auf eigene Faust ignorieren. Und hier fangen die IE-Probleme an.

Die File API von HTML5 erlaubt es, aus dem nichts Dateiressourcen zu erzeugen. Einfach mit new Blob(content, type) ein neues Blob-Objekt anlegen und fertig! Für sich genommen ist ein solches Objekt aber noch ziemlich nutzlos, denn ohne eine URL kann der Browser es außerhalb von JavaScript nicht verwenden. Mit Objekt-URLs lassen sich aber URLs auf beliebige JS-Objekte erzeugen, die dann benutzt werden können wie jede andere URL auch. Der folgende Schnipsel (hier auf jsFiddle) öffnet ein neues Fenster mit einer Textdatei, die es eigentlich gar nicht gibt; sie ist ein reines JavaScript-Konstrukt: 

var textFile = new Blob(['Hallo Welt!'], {
  type: 'text/plain'
});
var url = window.URL.createObjectURL(textFile);
window.open(url);

Auffällig an der URL des Popups ist, dass sie einen anderen Origin als die erzeugende Seite zu haben scheint; logisch, denn sie ist ja auch nicht der Seite selbst, sondern einem Script entsprungen: 

blob:http%3A//fiddle.jshell.net/753debc6-73cf-4349-a69f-c6c1e477286b

Natürlich wissen alle Browser, dass sie eine solche URL behandeln sollten, als hätte sie den gleichen Origin wie die Seite, die die URL erzeugt hat … es sei denn der Browser ist IE 10 oder 11 und versucht etwas mit Web Workers zu machen. Erzeugt man einen JavaScript-Blob und steckt diesen in den Worker-Constructor hinein, so werfen IE 10 und 11 einen SecurityError. Dieser ist eigentlich für den Fall reserviert, dass die die Constructor-Script-URL von einem fremden Origin kommt – und nicht mal Microsofts eigene Dokumentation behauptet, dass das hier der Fall sein könnte. dieses kleine Testscript produziert in allen modernen Browsern außer den IE 10 und 11 (und natürlich dem Android-Browser, der keine Web Workers kennt) ein Alert, im IE 10 und 11 eine Security-Exception.

Interessant ist, dass Web Workers die einzige API zu sein scheint, bei der dem IE dieses SOP-Fehlurteil unterläuft. Ajax-Requests auf Blob-URLs stellen jedenfalls kein Problem dar. Ob da wohl jede API ihre eigene SOP-Implementierung hat? Man weiß es nicht, aber das ist auch egal. Man soll ja nicht nur rumjammern, sondern sein Schicksal selbst in die Hand nehmen – also auf zum IE-Bugtracker!

Dort stellt man fest, dass dieses Problem schon mehrfach gemeldet, aber auf verschiedenste Weisen von Microsoft und der Gesellschaft zu Förderung von Textbausteinen abgebügelt wurde (1, 2, 3). Aus irgendwelchen Gründen hat mein Bug Report zu dem Thema (wer mehr als eine SOP-Implementierung hat, kann auch mehrere identische Bugreports aushalten) eine Antwort aus Textbausteinen bekommen, die nicht komplett ablehnend sind. Dass es explizit verboten ist, Dateien mit der Erweiterung .html an Bugreports für einen Webbrowser anzuhängen lässt mich zwar ein bisschen an der Ersthaftigkeit der ganzen Bugtracker-Operation zweifeln. Und ein Fix vor dem IE 12 ist natürlich ausgeschlossen. Aber immerhin!

Was ich jetzt gern von euch hätte, wäre dass ihr euch jetzt alle einen Microsoft-Account klickt und mit aller Macht den „betrifft mich ebenfalls“-Link in meinem Bug Report malträtiert. Ich würde erstens gern diesen Bug gefixt sehen, zweitens würde mich stark interessieren, ob wirklich irgendwer bei MS den Bugtracker zur Kenntnis nimmt. Dann wäre es nämlich wirklich mal an der Zeit, mit den billigen IE-Witzen aufzuhören.