IE-Problem mit durch XSL erzeugtes SCRIPT-Element
Mr. Horse
- javascript
Hallo,
ich hänge hier seit zwei Tagen zusammen mit einem für das Backend zuständigen Kollegen an einem extrem merkwürdigen Problem, das nur den IE betrifft.
Es wäre super, wenn Ihr da hilfreiche Hinweise - womöglich aus eigener Erfahrung - hättet.
Szenario:
Serverseitig erzeugt ein XML-Parser mit Hilfe eines XSL-Stylesheets ein XHTML-Dokument, das er an den Browser ausliefert. In das XHTML-Dokument werden nun verschieden JS-Dateien eingebunden:
<script type="text/javascript" src="lib/js/util.js"></script>
etc.
Die entstandene Seite ist valide und funktioniert in Firefox und Opera auch prächtig.
Problem:
IE6 und IE7 brechen das Rendern der Seite ab, sobald sie auf das erste Script-Element mit src-Attribut stoßen (das haben wir verifiziert durch Verschieben der Script-Tags ans Ende der Datei), obwohl der XHTML-Quellcode im Browsercache komplett vorhanden ist und alle Pfade stimmen.
Der IE5.5 zeigt ein leicht abweichendes Verhalten: er rendert die Seite vollständig, und nur das JS wird nicht geladen.
Versuche, das Problem einzukreisen:
Zusammenfassung:
Der IE bekommt eine intakte und valide XHTML-Datei vom Server, mit der andere Browser keine Probleme haben. Der IE jedoch bricht den Rendervorgang ab, sobald er auf ein Script-Element mit src-Attribut stößt.
Provisorische Lösung:
Als wir dann schon mit Voodoo anfingen, versuchte ich noch, die Script-Elemente zum Einbinden der JS-Dateien dynamisch per JS in das Dokument zu schreiben:
<script type="text/javascript"><![CDATA[ document.write('\u003csc' + 'ript type="text/javascript" src="lib/js/util.js"\u003e\u003c/sc' + 'ript\u003e'); ]]></script>
Und das klappt nun in allen Browsern, auch im IE....
Mal ehrlich: das ist doch völlig irrwitzig, oder?
Wir könnten nun diese provisorische Lösung beibehalten - lieber aber wäre uns, das Problem zu verstehen und wirklich zu lösen.
Danke für Eure Hilfe!
So long,
Mr. Horse
hi,
- Lädt man diese lokale Kopie auf den Entwicklungsserver und ruft sie von dort im IE auf - dann funktioniert noch immer alles! - Obwohl der Quellcode natürlich identisch ist mit dem der im IE nicht funktionierenden Seite, die vom XML-Parser geliefert wird.
Heisst das, "lokal" wird überhaupt nicht in einem HTTP-Umfeld getestet, sondern über file:// o.ä.?
gruß,
wahsaga
Hallo wahsaga,
Heisst das, "lokal" wird überhaupt nicht in einem HTTP-Umfeld getestet, sondern über file:// o.ä.?
ich weiß nicht, ob ich Deine Frage richtig verstehe.
Ich meinte, daß ich die betreffende im IE nicht funktionierende Seite per http://unserserver.tld/foo/bar.php5 aufgerufen und dann aus dem Browser heraus auf der Festplatte gespeichert habe - einfach mal, um zu sehen, was im Browser angekommen ist, und um dann ein wenig herumschrauben zu können.
Daß das Ganze dann im IE mit dieser lokal gespeicherten Kopie der Seite klappt, ist eben das Überraschende.
Wenn Du die von uns in den Dateien verwendeten Pfade meinst: wir haben es sowohl absolut als auch relativ versucht - keine Änderung des IE-Verhaltens.
So long,
Mr. Horse
hi,
Ich meinte, daß ich die betreffende im IE nicht funktionierende Seite per http://unserserver.tld/foo/bar.php5 aufgerufen und dann aus dem Browser heraus auf der Festplatte gespeichert habe - einfach mal, um zu sehen, was im Browser angekommen ist, und um dann ein wenig herumschrauben zu können.
Daß das Ganze dann im IE mit dieser lokal gespeicherten Kopie der Seite klappt, ist eben das Überraschende.
Dann würde ich mir mal die Response-Header anschauen, mit denen die beteiligten Ressourcen beim Zugriff über HTTP ausgeliefert werden - vielleicht stört den IE daran ja was.
gruß,
wahsaga
Hallo,
Dann würde ich mir mal die Response-Header anschauen, mit denen die beteiligten Ressourcen beim Zugriff über HTTP ausgeliefert werden - vielleicht stört den IE daran ja was.
hmm, ja, nur: die Ressourcen sind doch dieselben, wenn ich unsere provisorische Lösung einsetze. Die Requests an den Server sind doch unverändert - und damit auch die Antworten.
Aber ok, um sicherzugehen sollten wir das auf jeden Fall ebenfalls genau prüfen.
So long,
Andreas