Donnerstag, 11. Dezember 2008
Wenn Einen Gutes widerfährt…
… ist das schon einen Urlaub wert. Ok, der Urlaub war schon angemeldet und bewilligt. Ein altes Problem fast unmittelbar vorher zu lösen, sorgt dann aber doch für ein gutes Gewissen.
Die Lösung umfasst wenige Zeilen JavaScript-Code:
var elIframe = document.createElement('IFRAME');
elIframe.id = "MeineIFrame";
elIframe.width = '480px';
elIframe.height = '350px';
...
// später, wenn das Element eingehangen wurde:
...
elIframe.contentWindow.document.designMode = "on";
var win = elIframe.contentWindow;
var doc = win.document;
doc.open();
doc.write('');
doc.close();
...
Die Variable elIframe enthält ein IFrame-Element, der mit einem eindeutigen Identifier und einer festen Größe initialisiert wird. Nachdem das Element in den DOM eingefügt wurde, wird der DesignMode aktiviert, um darin schreiben zu können. Beachten Sie, dass der Frame kein Dokument mit dem src-Attribute referenziert. Zum Schluß schreiben wir nichts in den Frame. Das wir nichts in den Frame schreiben, ist aber die Lösung - bzw. sie können auch irgendetwas hineinschreiben, Hauptsache, sie rufen die write()-Methode auf.
Und wofür war das jetzt die Lösung? Dafür müssen einige Monate zurückgehen. Innerhalb eines CMS wurde der YUI Rich Text Editor eingebunden. Parallel dazu wird per AJAX der eigentliche Artikeltext geladen (siehe auch: YUI, Datei-Upload und ein zu cleverer Firefox). Der Artikeltext wird dann in den Editor geladen. Lokal funktionierte das auch wunderbar. Auf den Testserver hingegen gab es sporadische Aussetzer. Die Initialisierung des Editors schien auf halben Wege stehen zu bleiben.
Beim Testen fiel mir dann auf, dass es meist dann passierte, wenn ein vollständiger Reload erforderlich wurde, also sämtliche zur Webseite gehörenden Elemente inklusive JavaScript-Dateien usw. Bei einem einfachen Reload trat es selten auf, nachdem ich einen JS-Kompressor einsetzte, passierte es meist nur noch in einem von zehn Fällen. Das fand ich in dem Moment erstmal akzeptabel. Drückte man in solch einer Situation einfach F5, trat das Problem nicht erneut auf und es war auch verträglich mit der Applikationslogik.
Ich vermutete damals, dass die komplexe Initialisierung des YUI Editor in Kombinationen mit dem parallelen Laden der vielen Dateien und mehrere AJAX-Request irgendwo zu einer Deadlock-Situation führte.
Kommen wir zurück zum Heute. Der JavaScript-Code durchlief ein Re-Engineering, wobei ich komplett auf Events und Callbacks umsattelte. Und der YUI-Editor wurde - eher zufällig - durch eine einfachere Eigenkonstruktion ersetzt. Es lief auch alles wunderbar, selbst nach dem es auf den Testserver hochgeladen wurde.
Doch der ausgeführte Code beim Start wuchs und schließlich passierte es auch hier. Der Editor wollte nicht. Da das Problem irgendwo vollständig in meiner Verantwortung liegen musste, klemmte ich den Debugger an. Nur um festzustellen, dass es mit Debugger immer klappte und sämtlich Elemente perfekt initialisiert waren.
Ohne Debugger scheiterte aber folgende Aufruf meist:
elIframe.contentWindow.document.designMode = "on"; var win = elIframe.contentWindow; var doc = win.document; … // warte auf "Daten da"-Event doc.body.innerHTML = text;
Denn body war manchmal da, und manchmal eben nicht. Ich habe überprüft, ob der Event eventuell zu früh gefeuert wird, also bevor der IFrame überhaupt da ist - aber Fehlanzeige, selbst ein langer Timeout änderte nichts.
Und hier kam meine Vermutung: Offensichtlich scheint Firefox die Initialisierung des IFrames zu verschieben oder abzuwarten, wenn a.) parallel Datenrequests laufen und b.) beim Start keine Daten eingefügt werden.
Also kurzerhand:
doc.open();
doc.write('');
doc.close();
eingebaut und siehe da, seit dem funktioniert es wieder perfekt, write() zwingt Firefox
offensichtlich die internen DOM-Strukturen für den IFrame sofort anzulegen.
