Explorer refuses to execute replaceChild() in second or subsequent session window

In a project I'm currently working on I encountered an Explorer bug that depends on the window you open a page with.

I post it here because I know that MSIE team members occasionally read my blog, and I have the faint hope that can they solve this bug, especially since it's messing up one of my projects (and, after all, what in the world is more important than my projects going smoothly <grin>, particularly when I have another important and exciting project that should be finished quickly but is held up by this bug).

Summary

This bug occurs in a minority of IE6 installs on WinXP SP 2; and maybe on other Windows versions, too, but I haven't heard about them yet. If the bug occurs on a non-XP install, please leave a comment. On my computer the bug also occurs in IE 7 beta 2 preview 20 March.

The bug occurs in a rather complicated script that works with Windows Media and Real streaming content and with XMLHttp. The HTML contains a hard-coded <embed> tag that should be replaced by other content, if the bug weren't there. When I replace the hard-coded <embed> by a <div> the bug disappears. Unfortunately I haven't been able to further isolate it.

The bug occurs when you open the test page in a second or subsequent window of Internet Explorer. Then IE flatly refuses to execute a crucial replaceChild and gives an Interface Not Supported error. The script always works correctly when you restart Internet Explorer and load the test page in the first window that opens.

In summary: the script always works in the first window of your session, but in any of the subsequent windows (including, unfortunately, popups) an Interface not supported error may occur. In my checkered career I have never yet encountered a bug that depends on the window you open a page with.

Test page

This is the test page. Please open it; it should appear in a new window, and that new window is what triggers the bug. If you see an Interface Not Supported error the bug is active on your IE install. If the page works smoothly, your IE install doesn't contain the bug.

Discussion

The error occurs in metainformatie.js. The function verwijderNoscriptFilm() contains this line:

x.parentNode.replaceChild(y,x);

When opened in the second or subsequent window of a session, IE refuses to execute this line and gives an error message. Further on in the script another replaceChild is used (in data.js; Player.createNewEmbed), and when the script continues to this line it gives the same error message.

The HTML page contains an <embed> tag that loads a stream. When sufficient JavaScript is supported, this <embed> is replaced by a temporary placeholder <div>. Then the script loads some XML data, extracts a new stream URL and re-creates an <embed> to play this stream.

In principle this works fine in IE, Mozilla and Safari, and up to a point in Opera, which is why I chose this approach for the project. It was only when I tried to open the page in a popup that I discovered the bug.

The bug also occurs when I use removeChild, but not when I use appendChild. Apparently it's the removal of the hard-coded <embed> tag that causes the problem.

Replacing the <embed> tag by a <div> in the HTML source code solves the bug; it's definitely tied to the use of a hard-coded <embed> tag. Unfortunately, removing this <embed> makes my accessibility approach go down in shambles: the page is now inaccessible without advanced JavaScript (<sigh...>; sometimes you can't win, no matter how hard you try).

Do you see the error? If so, please tell me which IE version on which Windows version you're using. I'm especially interested in non-XP reports.

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m around at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies:

Comments

Comments are closed.

1 Posted by Barry van Oven on 27 April 2006 | Permalink

IE6 on Win2K SP4 crashes, so does Firefox 1.5.0.2. Opera works fine. You may not be interested in the other browsers, but I thought I'd just let you know. I can't test IE properly since the browser does CTD (crash to desktop).

2 Posted by Andreas Dölling on 27 April 2006 | Permalink

Hi,

using the link you provide above, I get the error message in IE6.0 and in IE 5.0 on a Windows 2000 (Professional) system, however _not_ in IE5.5.

But: I wrote a small test page just containing your EMBED element, and with this page your function verwijderNoscriptFilm() works in all my browsers.

Good luck!
Andreas

3 Posted by Chriztian Steinmeier on 27 April 2006 | Permalink

Bug not triggered on IE6/WinNT4

IE: 6.0.2800.1106
NT: 4.00.1381

4 Posted by Thany on 27 April 2006 | Permalink

Barry, for me it works perfectly in Firefox 1.5.0.2. maybe your particular version is broken, or it has to do with Win2000, since I use WinXP.

5 Posted by Spudley on 27 April 2006 | Permalink

Since you're especially interested in non-XP reports, I thought I should let you know that MSIE6 running on Linux under Wine doesn't seem to have the error. The page loads perfectly, and without any errors.

Hope that helps :)

(MSIE 6.0.2800.1106; SuSE Linux 9.3; Wine 0.9.11)

6 Posted by John Hansen on 27 April 2006 | Permalink

I've never used html to embed any kind of object, be it flash, java, realplayer, etc. So please take this as an honest question: Why not use the object tag instead?

http://htmldog.com/reference/htmltags/object/

It would be interesting to see if the same error occurs using object rather than embed.

Again, if I'm way off base suggesting this, please disregard this post =)

7 Posted by Jan Vermaat on 27 April 2006 | Permalink

One of my co-workers suggests it is some sort of chaching- or timing problem.
He tells me he saw this problem before(?). Does refreshing (F5) the page fix the error?

I think it maybe could be related to a security update from february
See: http://blogs.msdn.com/ie/archive/2005/02/09/369861.aspx and read the comments.

We can not reproduce the error here on Win2000 IE5.5 nor on XP SP2 IE6

8 Posted by Ballard Blevins on 27 April 2006 | Permalink

Have you tried just wrapping the EMBED tag in a DIV, and then removing the DIV?

Sure it would be annoyingly extraneous markup, but if it works around the problem . . .

9 Posted by Alex Lein on 27 April 2006 | Permalink

I got a 2 javascript errors with the latest IE7 Beta 2 (5346), but after i reloaded the page (telling it to run the ActiveX controls) it worked fine.

10 Posted by Liam Hesse on 27 April 2006 | Permalink

I haven't been able to raise this bug on my work PC with MSIE (6.0.2900.2180.xpsp_sp2_gdr.050301-1519). I followed the instructions - I opened this page in MSIE, then clicked on the link which then opened it in a new window. No bug for me.

If it's at all helpful, perhaps I should mention that my work PC is a 3GHz P4 with 1GB RAM, just in case it *does* turn out to be a timing issue.

It occurs to me, since I'm behind a corporate firewall which blocks Windows Update, I may not have the Eolas hack^H^H^H^Hpatch installed. Could that be a cause of this problem?

11 Posted by Ivan Bushmarinov on 27 April 2006 | Permalink

The page loads without any errors in MSIE on Win2000 SP4
(IE version: 6.0.2800.1106, Windows 5.00.2195)

In Firefox 1.5.2 the test page loads smoothly too.

12 Posted by Mark McDonnell on 27 April 2006 | Permalink

I just received a different error from the following function. It flashed up quickly and didn't repeat itself again?

it noted the error coming from the line "self.resizeBy(0,1);"?

function finishInitialize() // als alles geinitialiseerd is
{
self.resizeBy(0,1);
self.resizeBy(0,-1);
sizeMetaInfo();
window.onresize = sizeMetaInfo;
}

thought you might find this helpful in case it was indeed an error that had been overlooked.

13 Posted by Koen "Grubolsch" Eelen on 7 May 2006 | Permalink

Maybe you find this interesting, PPK, I did the test on my windows 98 here (with IE 6), and it worked!
I also did the change to do the test with IE 5, on the same operating system, and nothing occured.
Hope that helps you (is happy to do something back after a full year of lurking)