Beautiful interfaces& solid&smart backends make todays web work.

About Maik Vlcek Follow me on twitter
Themenschwerpunkte dieses Blogs:

Probleme mit sIFR 3 und SWFObject auf einer Seite im IE 6 und 7

IE Voodoo Doll
Share and Enjoy: Diese Icons verlinken auf Bookmark Dienste bei denen Nutzer neue Inhalte finden und mit anderen teilen können.
  • MisterWong
  • Digg

Dieser Bugfix wird in neuen sIFR 3 builds nicht mehr benötigt: vgl. UPDATE 11.04.08 weiter unten und die Kommentare.

———-

In einem Projekt bin ich vor Kurzem auf ein seltsames Verhalten von sIFR 3 gestoßen.

Problembeschreibung

Komischerweise zeigte meine Testseite im Internet Explorer 6 und 7 keinen Inhalt an. Der XHTML Quelltext blieb (fast) leer.

Alles was im Quelltext stand war

<script src="wp-content/themes/meinTheme/swf/meineFont.swf" type="sifr/prefetch"></script>

… ansonsten war die Seite weiß und leer.

Nach einer kurzen Recherche bin ich dann auf den Beitrag von EightEightZero gestoßen, welcher auch mit dem Problem zu kämpfen hatte, aber einen Bugfix anbietet. Das Problem taucht bei Verwendung von sIFR 3 und SWFObject 1.5 auf ein und derselben Seite auf. Leider hat das Setzen des im Bugfix beschriebenen Parameters keine Wirkung in meiner Testumgebung gezeigt.

Nach weiterem Stöbern in der Dokumentation von sIFR 3 bezüglich der Javascript Konfiguration und einigen sIFR-Foren-Beiträgen habe ich letzendlich die passende Lösung gefunden. Der Parameter hat in der von mir verwendeten Version von sIFR (version 3, revision 382) einfach einen anderen Namen bekommen:

sIFR.useDomLoaded = !sIFR.ua.ie;

Dies teilt sIFR mit, dass es im IE (sIFR.ua.ie > true, wenn IE) die useDomLoaded-Funktionalität nicht anwenden soll. Nach dem Löschen des Cache sollte die Seite nun ohne Probleme im Internet Explorer 6 und auch in der 7er Version des IE angezeigt werden.

Wichtig: Dieser Parameter muss nach sIFR.prefetch und vor sIFR.activate gesetzt werden

UPDATE 11.04.08:

Ich bin jetzt auf die sIFR Version 3 r395 umgestiegen und der oben beschriebene Bugfix ist nicht mehr nötig.

Dabei ist mir noch eins aufgefallen: Wer Probleme mit sIFR und mootools hat, sollte sicherstellen, dass der sIFR Code (sIFR.replace usw) nicht in einem onDomReady-Event eines Javascript-Frameworks wie z.B. mootools steht, da sonst Fehler im IE entstehen. sIFR nutzt eine eigene domReady-Methode.

Leider taucht in dieser Version ein andere Bug auf: Fehlerhaftes Scollverhalten im Internet Explorer. Wenn die Maus über einem Flash-Element steht, kann man die Seite im Internet Explorer nicht mehr scrollen.

Publiziert am 09. Apr. 2008 von mediavrog in , , , , , , . Kategorie: IE.

Share and Enjoy: Diese Icons verlinken auf Bookmark Dienste bei denen Nutzer neue Inhalte finden und mit anderen teilen können.
  • Y!GG
  • MisterWong
  • Linkarena
  • Facebook
  • TwitThis
  • email
  • del.icio.us
  • Digg
  • StumbleUpon
  • Technorati
Monster-Me eating knowledge
3 Responses RSS Icon
Trackback URL
  1. Hej, you shouldn’t have to use this workaround in recent sIFR 3 builds. Could you verify?

  2. mediavrog sagt:

    Hi Mark,

    i updated to the last revision (397) and didn’t encounter the need for the bugfix above. I therefore updated my post.
    Thanks.

  3. Andre sagt:

    @Mark: Ahhh – thanks for this tip!

top top