IE lädt per Javascript eingebundenen Flashfilm nicht

[Felix Riesterer]

Liebe Forumsgemeinde,

ich habe ein optisches Problem mit Javascript zu lösen versucht, was im FF auch klappt, im IE wieder einmal aber nicht. Ach ja, Opera 8.5 lässt mich nichteinmal den Link benutzen, es sei denn, ich stelle mein CSS auf "Author Mode"...

Problem:
Flashfilme haben immer den größten z-Index und überlagern so selbst Inhalte, die eigentlich über den Filmen liegen sollten. In meinem Falle scheint Marc Reichelts EMFF durch mein Bilder-Popup.

Lösungsansatz:
Flash nur bei Bedarf tatsächlich einbinden, damit kein <object>-Element existiert, welches "durchscheinen" könnte. Daher soll Javascript das <object>-Element auf einen Klick hin in den DOM-Tree einbinden und einen Platzhalter dadurch ersetzen.

Ergebnis:
Der DOM-Inspector zeigt mir exakt dasselbe an, was vorher statisch im HTML-Quelltext stand. Daher scheint mein Javascript mit seiner Ersetzung erfolgreich gewesen zu sein. Im IE "kommt aber nix". Ein Rechtsklick auf die Plugin-Fläche meldet "Film nicht geladen".

Was tun? Liegt es vielleicht am missratenen Microsoft-Patch, der die Zugänglichkeit zu aktiven Inhalten aus Patentrechtsgründen erschweren soll? Aber warum hat dann die statische Version kein solches Verhalten gezeigt?

Ansichtssachen: statische Lösung, dynamische Lösung (das JavaScript)

Es kann doch nicht sein, dass ich der erste bin, der dieses Problem hat...!?

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Jonas]

Liebe Forumsgemeinde,

Problem:
Flashfilme haben immer den größten z-Index und überlagern so selbst Inhalte, die eigentlich über den Filmen liegen sollten. In meinem Falle scheint Marc Reichelts EMFF durch mein Bilder-Popup.

Es gibt eine möglichkeit Flashfilme im Hintergrund zuhalten:

  
<object classid="bla" codebase="bla" width="11" height="11" title="bla">  
  <param name="movie" value="res/test.swf" />  
  <param name="quality" value="high" />  
  <param name="wmode" value="transparent" />  
  
  <embed wmode="transparent" src="res/test.swf" quality="high" pluginspage="bla" type="application/x-shockwave-flash" width="11" height="11"></embed>  
</object>  

Das worauf es ankommt ist 'wmode' einerseits als <param> für <object> und als Attribut für <embed>.
Der <embed> Tag ist leider nötig ansonsten klappts beim IE nicht (HTML ist nacher nicht mehr valid).

Gruss
Jonas

[Felix Riesterer]

Lieber Jonas,

~~~html

<param name="wmode" value="transparent" />

<embed wmode="transparent" src="res/test.swf" quality="high" pluginspage="bla" type="application/x-shockwave-flash" width="11" height="11"></embed>

> Das worauf es ankommt ist 'wmode' einerseits als <param> für <object> und als Attribut für <embed>.  
> Der <embed> Tag ist leider nötig ansonsten klappts beim IE nicht (HTML ist nacher nicht mehr valid).  
  
vielen Dank für diesen Hinweis. Ich werde es ausprobieren, jedoch löst es mein Javascript-Problem nicht. Außerdem hätte ich mir eine valide Lösung (daher Javascript) gewünscht - auch für den IE (ohne Conditional Comments).  
  
Liebe Grüße aus [Ellwangen](http://www.ellwangen.de/),  
  
Felix Riesterer.

[Struppi]

Lösungsansatz:
Flash nur bei Bedarf tatsächlich einbinden, damit kein <object>-Element existiert, welches "durchscheinen" könnte. Daher soll Javascript das <object>-Element auf einen Klick hin in den DOM-Tree einbinden und einen Platzhalter dadurch ersetzen.

Veruschs doch einfach mal mit innerHTML.

Struppi.

[Felix Riesterer]

Lieber Struppi,

vergleiche selbst: innerHTML-Version

Im Alert sollte ein <object>-Element erscheinen. Im FF (1.5) und Opera (8.5) erscheint es auch, im IE (5.0 - 6) dagegen nicht, was mich zu dem Schluss führt, dass die RegEx-Engine im IE eine megagroße Macke hat (wen wundert bei diesem Schandwerk noch irgendetwas!?). Oder warum versteht er mein Suchmuster nicht?

Damit scheitert wohl auch der innerHTML-Ansatz... Bin ich sauer!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Struppi]

vergleiche selbst: innerHTML-Version

Kann ich nicht, hab kein Flash.

Im Alert sollte ein <object>-Element erscheinen. Im FF (1.5) und Opera (8.5) erscheint es auch, im IE (5.0 - 6) dagegen nicht, was mich zu dem Schluss führt, dass die RegEx-Engine im IE eine megagroße Macke hat (wen wundert bei diesem Schandwerk noch irgendetwas!?). Oder warum versteht er mein Suchmuster nicht?

Warum so umständlich?
Warum nicht einfach:

var ersetzung = ....
platzhalter.parentNode.innerHTML = ersetzung;

Struppi.

[Felix Riesterer]

Lieber Struppi,

Warum nicht einfach:

var ersetzung = ....
platzhalter.parentNode.innerHTML = ersetzung;

Die Ersetzung selbst ist ein <object>-Element, der Platzhalter ist ein <div>-Element. Es soll das DIV selbst ersetzt werden. Dazu verwende ich die parentNode des DIVs, um _darin_ das DIV durch das OBJECT zu ersetzen, nicht etwa um den Inhalt des DIVs mit dem OBJECT zu überschreiben.

Ich will ja schon fast lieber nicht mehr wissen, ob im IE7 solch eklatante Patzer in der JavaScript/JScript-Engine behoben wurden...

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Struppi]

Warum nicht einfach:

var ersetzung = ....
platzhalter.parentNode.innerHTML = ersetzung;
Die Ersetzung selbst ist ein <object>-Element, der Platzhalter ist ein <div>-Element. Es soll das DIV selbst ersetzt werden. Dazu verwende ich die parentNode des DIVs, um _darin_ das DIV durch das OBJECT zu ersetzen, nicht etwa um den Inhalt des DIVs mit dem OBJECT zu überschreiben.

Versuch's doch erstmal so einfach wie möglich. Im Zweifelsfall kannst du es auch mit outerHTML probieren. Aber auf keinen Fall würde ich innerHTML mit einem regulären Ausdruck bearbeiten.

Ich will ja schon fast lieber nicht mehr wissen, ob im IE7 solch eklatante Patzer in der JavaScript/JScript-Engine behoben wurden...

Ich denke nicht dass das ein Patzer ist. Das Problem ist vermutlich, dass du quasi live innerHTML mit einer regulären Ausdruck tauschen möchtest. Das dürfte intern aber einiges an Schwierigkeiten verursachen. Du musst dir im klaren sein, dass innerHTML nicht einfach ein String ist, sondern wenn du innerHTML einen Wert zuweist, wird der Browser dazu veranlasst diesen String zu parsen und unmittelbar darzustellen. Und dann überleg was ein regulärer Ausdruck machen muss, dass in der Kombination von beiden der Browser sich verschlucken kann, ist zumindest nicht verwunderlich

Struppi.

[Felix Riesterer]

Lieber Struppi,

Danke für Deine Tipps.

Das Problem ist vermutlich, dass du quasi live innerHTML mit einer regulären Ausdruck tauschen möchtest.

Also wird bei
var HTML = element.innerHTML;
der Variablen HTML nur eine Referenz auf die Eigenschaft "innerHTML" des Objektes "element" übergeben, anstatt der Inhalt dieser Eigenschaft als String?

Ich muss das einmal Prüfen. Folgende Seite sollte Auskunft geben können:

<html><head><title>test</title>  
<style type="text/css">  
#original { background: green; }  
#ersetzung { background: red; }  
</style>  
<script type="text/javascript">  
function test(testobjekt) {  
var HTML = testobjekt.innerHTML;  
alert('innerHTML vorher:\n'+testobjekt.innerHTML);  
alert('Wert der Variablen "HTML":\n'+HTML+'\n\nVariable "HTML" ist vom Typ: '+typeof(HTML));  
testobjekt.innerHTML = '<p id="ersetzung">Dieser Absatz wurde eingefügt</p>';  
alert('innerHTML hachher:\n'+testobjekt.innerHTML);  
alert('Wert der Variablen "HTML":\n'+HTML);  
}  
</script>  
</head>  
<body>  
<div onclick="test(this);"><p id="original">Dieser Absatz kann durch einen Klick ver&auml;ndert werden!</p></div>  
</body>  
</html>

Wie man sieht, ist die Variablen HTML tatsächlich ein String (auch im IE!) und wird auch durch ein Verändern von innerHTML des Elementes, aus dem sie ursprünglich ihren Wert bezog, nachträglich nicht manipuliert!

Warum kann also dieses Schandwerk von IE nicht einfach das tun, was eine syntaktisch und logisch korrekte Programmierung verlangt?!!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Struppi]

Das Problem ist vermutlich, dass du quasi live innerHTML mit einer regulären Ausdruck tauschen möchtest.

Also wird bei
var HTML = element.innerHTML;
der Variablen HTML nur eine Referenz auf die Eigenschaft "innerHTML" des Objektes "element" übergeben, anstatt der Inhalt dieser Eigenschaft als String?

Nein, umgekehrt der Inhalt wird als String übergeben. Allerdings ist die Zuweisung keine normale Stringzuweisung es passiert ja was.

Deutlicher wird das, wenn du in deinem Beispiel mal eine Tabelle einfügst:

  
var HTML = testobjekt.innerHTML;  
testobjekt.innerHTML = '<table><tr><td>Dieser Absatz wurde eingefügt</td></tr></table>';  
alert('innerHTML hachher:\n'+testobjekt.innerHTML);

Wie du siehst sind die Tags in Großbuchstaben umgewabdelt worden und ein TBODY Element eingefügt worden.

Warum kann also dieses Schandwerk von IE nicht einfach das tun, was eine syntaktisch und logisch korrekte Programmierung verlangt?!!

Weil eben mehr passiert als du erwartest.

Struppi.

[Felix Riesterer]

Lieber Struppi,

Nein, umgekehrt der Inhalt wird als String übergeben. Allerdings ist die Zuweisung keine normale Stringzuweisung es passiert ja was.

Warum kann also dieses Schandwerk von IE nicht einfach das tun, was eine syntaktisch und logisch korrekte Programmierung verlangt?!!

Weil eben mehr passiert als du erwartest.

ich stelle fest, dass ich Dich schon richtig verstanden habe.

Bei der Wertzuweisung element.innerHTML = string; passiert selbstverständlich wesentlich mehr (DOM-Knoten erstellen und einhängen). Das wollte ich auch nie bezweifelt haben.

Aber was passiert bei variable = element.innerHTML? Es wird einer Variablen ein String zugewiesen! Und genau hier fängt mein Problem im IE an:

Diesen String kann der IE mittels variable.replace() nicht korrekt ersetzen.
Merke: Diese Stringoperation ist für sich genommen völlig losgelöst vom innerHTML-Kontext. Dein Einwand aus einem vorigen Posting von wegen "quasi live innerHTML mit einer regulären Ausdruck tauschen" passt somit nicht auf diese Situation (siehe mein Code-Beispiel aus meinem vorigen Posting). Es scheint, als ob der IE einfach den regulären Ausdruck nicht korrekt auf den String matchen kann (warum auch immer, denn andere Browser können das!!). Und genau hierher rührt mein Vorwurf (Stichwort "Patzer") an die Macher dieses markenbenamsten Bugs!

Liebe Grüße aus Ellwangen,

Felix Riesterer.

[Vinzenz Mai]

Hallo Felix,

Aber was passiert bei variable = element.innerHTML? Es wird einer Variablen ein String zugewiesen! Und genau hier fängt mein Problem im IE an:

das stimmt :-)

Diesen String kann der IE mittels variable.replace() nicht korrekt ersetzen.

Sagen wir so: Die von Dir gewünschte Ersetzung kann nicht vorgenommen werden. Das ist ein Unterschied. Auf diesen Unterschied komme ich später zurück.

Es scheint, als ob der IE einfach den regulären Ausdruck nicht korrekt auf den String matchen kann (warum auch immer, denn andere Browser können das!!).

er kann es, das Ergebnis ist: Nichts gefunden. Andere Browser finden im exakt gleichen String ebenfalls nichts. Sie verhalten sich genauso wie der IE. Deine Behauptung, andere Browser könnten das, ist somit einfach falsch.

Und genau hierher rührt mein Vorwurf (Stichwort "Patzer") an die Macher dieses markenbenamsten Bugs!

Dein Vorwurf in dieser Form ist unberechtigt. Du wendest eine ungeeignete Methode an, weil Du in einem String etwas anderes erwartest als darin steht.

Wo ist nun das Problem, wie ist es zu lösen:

Das Problem steckt in der Zeichenfolge, die der IE als innerHTML zurückliefert. Wie Struppi schreibt, passiert mehr als man nach außen direkt sieht.

Ich habe mir den Inhalt Deiner Variablen HTML als Zeichennummern zeilenweise in einer Textarea ausgeben lassen. Dabei habe ich festgestellt, dass in der Zeichenfolge im IE wiederholt die Kombination 10 13 (\r\n) vorkommt, der typische Zeilenumbruch von Windows.

Wendest Du einen regulären Ausdruck auf eine Zeichenfolge an, der diese Kombination enthält, so wird dort aufgehört. Dieses Verhalten ist konsistent in Firefox und IE. Daraus ergibt sich unmittelbar die Lösung für Dein Problem: Du musst diese "Zeilenumbrüche" entfernen, z.B. über

  
    var HTML = platzhalter.parentNode.innerHTML;  
    var teile = HTML.split("\r\n");  
    HTML = teile.join("");  

Warum Du überflüssigerweise ein RegExp-Objekt erzeugst, hab' ich nicht verstanden. Ich bin der Empfehlung von SELFHTML gefolgt und habe die Ersetzung gleich wie folgt vorgenommen:

  
    var resultat = HTML.replace(/<div.*<\/div>/i, ersetzung);  

wobei ich Deinen regulären Ausdruck vereinfacht habe. Mir kamen die beliebig vielen Nicht-Größer-Zeichen, gefolgt von einem Größer-Zeichen überflüssig vor. Bei diesem einfachen Matching sicherlich Geschmacksache. Jedenfalls lieferte der so modifizierte Code sowohl in IE als auch im Firefox das von Dir gewünschte Ergebnis.

Freundliche Grüße

Vinzenz

[Felix Riesterer]

Lieber Vinzenz,

Ich habe mir den Inhalt Deiner Variablen HTML als Zeichennummern zeilenweise in einer Textarea ausgeben lassen. Dabei habe ich festgestellt, dass in der Zeichenfolge im IE wiederholt die Kombination 10 13 (\r\n) vorkommt, der typische Zeilenumbruch von Windows.

Sollte das der multiline-Mode nicht berücksichtigen? Da ein /im am Ende des Suchmusters nichts brachte, habe ich ihn wieder weggelassen... Aber wenn es alleine daran liegt, dann verstehe ich, warum ich nicht weiter kam!

Wendest Du einen regulären Ausdruck auf eine Zeichenfolge an, der diese Kombination enthält, so wird dort aufgehört. Dieses Verhalten ist konsistent in Firefox und IE.

Seltsam nur, dass der Firefox das Suchmuster matched, während der IE es nicht tut... Wandeln FF und Opera heimlich \r\n zu \n?

Daraus ergibt sich unmittelbar die Lösung für Dein Problem: Du musst diese "Zeilenumbrüche" entfernen, z.B. über

var HTML = platzhalter.parentNode.innerHTML;
    var teile = HTML.split("\r\n");
    HTML = teile.join("");

Das werde ich nun tun. Vielen Dank!  
  

> Warum Du überflüssigerweise ein RegExp-Objekt erzeugst, hab' ich nicht verstanden. Ich bin der Empfehlung von SELFHTML gefolgt und habe die Ersetzung gleich wie folgt vorgenommen:  

Naja... war ich wieder einmal "päpstlicher als der Papst"...  
  

> `var resultat = HTML.replace(/<div.*<\/div>/i, ersetzung);`{:.language-javascript}  
> wobei ich Deinen regulären Ausdruck vereinfacht habe.  

Ist in diesem Kontext sinnvoll. Auch dafür Dank!  
  
Mein Problem ist nun [erfolgreich gelöst](http://www.peutinger-gymnasium.de/html/wie/bilder/index.html). Mit innerHTML konnte ich den Flashfilm im IE dynamisch einbinden, was über die DOM-Methoden mit `document.createElement() und element.appendChild()`{:.language-javascript} nicht gelingen wollte, da der IE dann den Flashfilm nicht laden wollte. Warum das so ist, hätte ich zwar gerne gewusst, muss es aber leider auf sich beruhen lassen. Deswegen werde ich weiterhin (wenn auch weniger laut) über die Redmonder schimpfen. ;-)  
  
Liebe Grüße aus [Ellwangen](http://www.ellwangen.de/),  
  
Felix Riesterer.

[Vinzenz Mai]

Hallo Felix,

Wendest Du einen regulären Ausdruck auf eine Zeichenfolge an, der diese Kombination enthält, so wird dort aufgehört. Dieses Verhalten ist konsistent in Firefox und IE.
Seltsam nur, dass der Firefox das Suchmuster matched, während der IE es nicht tut... Wandeln FF und Opera heimlich \r\n zu \n?

Nö, deren innerHTML enthält keine Zeilenumbrüche :-)
Übrigens habe ich das ganze etwas genauer geprüft

Opera (8.54 Windows), Firefox (1.5.0.2 Windows, 1.0.7 Linux) und IE trennen Bereiche an \r, an \n und natürlich an der Kombination. Konqueror 3.4.1 hingegen sieht \r nicht als Trennzeichen für Bereiche an, \n hingegen schon.

Wie das innerHTML in Opera und Konqueror aussieht, habe ich mir noch nicht angeschaut, will ich aber noch nachholen. Irgendwelche praktischen Auswirkungen des Modifiers m, den ich selbstverständlich auch geprüft habe, konnte ich nicht finden :-(

Mit innerHTML konnte ich den Flashfilm im IE dynamisch einbinden, was über die DOM-Methoden mit document.createElement() und element.appendChild() nicht gelingen wollte, da der IE dann den Flashfilm nicht laden wollte. Warum das so ist, hätte ich zwar gerne gewusst, muss es aber leider auf sich beruhen lassen.

Ich kann mich nicht mehr daran erinnern, wie Dein Versuch genau aussah und finde auch nichts im Archiv dazu. Allerdings steht in der MSDN, dass Du z.B. für param innerHTML benötigst.

Freundliche Grüße

Vinzenz

[Felix Riesterer]

Lieber Vinzenz,

Übrigens habe ich das ganze etwas genauer geprüft

Opera (8.54 Windows), Firefox (1.5.0.2 Windows, 1.0.7 Linux) und IE trennen Bereiche an \r, an \n und natürlich an der Kombination. Konqueror 3.4.1 hingegen sieht \r nicht als Trennzeichen für Bereiche an, \n hingegen schon.

Wie das innerHTML in Opera und Konqueror aussieht, habe ich mir noch nicht angeschaut, will ich aber noch nachholen. Irgendwelche praktischen Auswirkungen des Modifiers m, den ich selbstverständlich auch geprüft habe, konnte ich nicht finden :-(

sehr interessante Beobachtungen! Vielen Dank, denn dieses erklärt ein wenig, warum ich mich habe wundern müssen.

Allerdings steht in der MSDN, dass Du z.B. für param innerHTML benötigst.

Der IE versteht wohl das <param>-Element nicht als gültiges DOM-Element. Daher konnte eine Einbindung per document.createElement() nicht wirklich gelingen, obwohl der IE zumindest das <object> korrekt erzeugt hat. Aber anscheinend musste der Inhalt des <object>s per innerHTML, anstatt auch per document.createElement() erzeugt werden, damit der Flash-Film tatsächlich geladen wird.

Ich werde wohl nie wirklich keinen Grund mehr haben, um auf die schlampige Implementierung standardisierter Features bei Murksesaft schimpfen zu müssen. Schade eigentlich!

Liebe Grüße aus Ellwangen,

Felix Riesterer.