Changing IFrame Src Leak in Internet Explorer

  • Thread starter Archimedes Trajano
  • Start date
A

Archimedes Trajano

I wrote out a simple experiment to test changing the contents of an
IFrame using src and I found that it leaks when I change the src
attribute. This happens in Internet Explorer 6 but I have not tried
to do measurements on other browsers. The leak only manifests when
using PerfMon to monitor the private bytes over time for the
iexplore.exe process. I have verified that sIEve will not show any
leaks.

I actually found a solution that does not use the src attribute that
does not leak, but I am trying to determine if I am alone in seeing
this behaviour/leak pattern (which I don't I am alone). The leak
shows a linear growth and it becomes visible as the the "click me"
text is clicked continuously.

The closest topics that I found when researching this problem are in
the comp.lang.javascript newsgroup. However, both do not state any
working result.

* Dan Edgar - Internet Explorer Massive IFRAME Memory Leaks
* Tõnu Näks - Javascript Memory Leak

At present I am still trying to retrofit my non-leaking solution into
an existing framework with no luck, so I am trying to see if there are
other known workarounds on this behaviour so I don't need to make many
invasive changes in the framework. The solution that does not leak
uses Ajax in using the prototypejs library and do a document.write(),
document.close() to clear and replace the content.

The following is the leaking source. I have tried to keep it as short
as possible and add as much comments as possible.

<html>
<head>
<style>
..bufferFrame {
display: block; /* for now so we can see the contents of the buffer
frame */
position: absolute; top: 0; left: 1024px; width: 1024px; height:
768px;
}
..appFrame {
display: block;
position: absolute; top: 0; left: 1024px; width: 1024px; height:
768px;

}
</style>
<script>
var onFrame = 0;
// This gets executed when the page gets loaded
// Used this approach to get rid of the closure and obvious leak shown
in sIEve
function handleSwitch() {
document.all[onFrame].className = "bufferFrame"
event.srcElement.className = "appFrame"
onFrame = event.srcElement.id
}
// page = URL
// obj = the object that triggered the event
function nav(page,obj) {
// Prevent double clicks
obj.onmousedown = null

var bufferFrame = (onFrame == "frame0") ? "frame1": "frame0"
document.all[bufferFrame].src = page
document.all[bufferFrame].attachEvent("onload", handleSwitch)
}

function load() {
onFrame = "frame0";
}
</script>
</head>
<body onload="load()">
<iframe id="frame0" src="buffer1.html" class="appFrame"></iframe>
<iframe id="frame1" src="foo.html" class="bufferFrame"></iframe>
</body>
</html>

The contents of buffer1.html starts with

<html>
<head>
<title>buffer1</title>
</head>
<body id="bbuffer1" >
<p>Buffer 1</p>
<div id="buffer1" onmousedown='top.nav("buffer2.html", this)'>click
me</div>
<p>
.... large number of text about 100K to make the memory grow as
quickly as possible, I use the http://www.lipsum.com/ to generate the
text
</p>
</body>
</html>

There is a buffer2.html file which is the same as buffer1.html except
it points to buffer3.html

<html>
<head>
<title>buffer2</title>
</head>
<body id="bbuffer2" >
<p>Buffer 2</p>
<div id="buffer1" onmousedown='top.nav("buffer3.html", this)'>click
me</div>
<p>
.... large number of text about 2MB to make the memory grow as quickly
as possible, I use the http://www.lipsum.com/ to generate the text
</p>
</body>
</html>

There is a buffer3.html file which is the same as buffer1.html except
it points to buffer1.html

<html>
<head>
<title>buffer3</title>
</head>
<body id="bbuffer3" >
<p>Buffer 3</p>
<div id="buffer1" onmousedown='top.nav("buffer1.html", this)'>click
me</div>
<p>
.... large number of text about 1MB to make the memory grow as quickly
as possible, I use the http://www.lipsum.com/ to generate the text
</p>
</body>
</html>

foo.html is just

<p>foo</p>
 
H

Henry

I wrote out a simple experiment to test changing the contents
of an IFrame using src

The W3C HTML DOM spec contains nothing that suggest that assigning to
the - src - property of an IFRAME element can be expected to result in
navigation within that IFRAME.
and I found that it leaks when I change the src
attribute. This happens in Internet Explorer 6 but I have
not tried to do measurements on other browsers. The leak
only manifests when using PerfMon to monitor the private
bytes over time for the iexplore.exe process. I have
verified that sIEve will not show any leaks.

Which suggests that you are observing a "PefMon" artefact/bug not an
IE 6/brower/javascript issue.
I actually found a solution that does not use the src
attribute that does not leak, but I am trying to determine
if I am alone in seeing this behaviour/leak pattern (which
I don't I am alone). The leak shows a linear growth and it
becomes visible as the the "click me" text is clicked
continuously.
The following is the leaking source. I have tried to keep
it as short as possible and add as much comments as possible.

<html>
<head>
<style>
.bufferFrame {
display: block; /* for now so we can see the contents of the buffer
frame */
position: absolute; top: 0; left: 1024px; width: 1024px; height:
768px;}

.appFrame {
display: block;
position: absolute; top: 0; left: 1024px; width: 1024px; height:
768px;

}

</style>
<script>
var onFrame = 0;
// This gets executed when the page gets loaded
// Used this approach to get rid of the closure and obvious leak
shown
in sIEve
function handleSwitch() {
document.all[onFrame].className = "bufferFrame"
event.srcElement.className = "appFrame"
onFrame = event.srcElement.id}

// page = URL
// obj = the object that triggered the event
function nav(page,obj) {
// Prevent double clicks
obj.onmousedown = null

var bufferFrame = (onFrame == "frame0") ? "frame1": "frame0"
document.all[bufferFrame].src = page
document.all[bufferFrame].attachEvent("onload", handleSwitch)

Unlike the W3C DOM method for attaching listeners (i.e.
addEventListener) the Microsoft method (attachEvent) does not reject
multiple attempts to attach the same function object as a listener. If
you attach - handleSwitch - on each attempt at navigation then it will
be executed multiple times, once for each previous call to your - nav
- function.
}

function load() {
onFrame = "frame0";}

</script>
</head>
<body onload="load()">
<iframe id="frame0" src="buffer1.html" class="appFrame"></iframe>
<iframe id="frame1" src="foo.html" class="bufferFrame"></iframe>
</body>
</html>

The contents of buffer1.html starts with
<snip>

With the various 'buffer' pages padded up to 2.8 megabytes each and
the faults in your 'test' page fixed so that it is workable,
navigating between the various 'buffer' pages showed no evidence of
memory leaks on IE 6 (memory consumption fluctuated but was more or
less consistent over time, and certainly did not show any significant
upward steps on each navigation).

Given that your 'test' page was unworkable 'out of the box' (even
disregarding the line wrapping of over long comments (predictably)
caused by posting) it is obvious that you did not actually test the
code you posted to see if it did exhibit the issue you attributed to
it (else you would have seen that it was not workable). That was a
waste of everyone's time.

If you really have a memory leak issues, and want someone else to
identify the cause and effect relationships behind it, you need to
post a minimal test case that actually exhibits the issue, for which
you will need to verify that it does exhibit the issue before posting
it.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,053
Latest member
BrodieSola

Latest Threads

Top