IE6 memory leak - very fiddly

Hi all,

I've been trying to pin down a memory leak in IE6 for several WEEKS
now. I've done my share of googling etc., and know all about common
leaks like circular references and closures, but have found nothing like
this.
This app is designed to run in a kiosk environment, so it has
things like a persistent frame which holds data as well as the visible
frame (actually an iframe). After 1,000 page transitions our app is up
by almost 20MB; considering kiosks can run for days or even weeks this
is definitely not ideal. There's definitely a lot of stuff happening,
but I've managed to pin the leak down to a very odd case.

I have two identical test pages which I click between using a
navigate() function. I am absolutely sure that the tags in question have
their event handlers set to null before the page is navigated away from.

The following shows the leak (apologies, my news server disallows
HTML tags):

[a onmousedown="navigate('testPage2.html');"]CLICK ME[/a]

The following does NOT leak (there's a small leak but nowhere near
as much):

[a href='#' onmousedown="navigate('testPage2.html');"]CLICK ME[/a]

The following DOES leak:

[a onmousedown="location.href='#';navigate('testPage2 .html');"]CLICK ME[/a]

Does anyone have any clue why this might be, ignoring the mass of
code that gets executed on page load/unload? Why would clicking that
link not leak only when there's an href assigned? Does that do something
weird to the event bubbling, perhaps? Or fire an extra event (or *not*
fire some other event)? And why wouldn't the magic also trip when
location.href is assigned via JavaScript?

Anyone who has any idea about this is invited to make my life a lot
happier. Thanks very much!

--Daniel Orner

re: IE6 memory leak - very fiddly

Wouldn't the "location.href='#'" reload the page, thereby reinitialize
any event handlers you have in your code? What does "navigate()" do,
besides the obvious I mean...

re: IE6 memory leak - very fiddly

kit.ludwick wrote:No, I tried it and it doesn't reload the page, at least on IE6. And if
it did, the same thing would have happened in the onmousedown handler,
and yet they act differently.
The navigate() basically moves to the next page. Like I said, there's a
lot of stuff going on there (there are several frames/iframes involved),
but I'd like to concentrate on the difference between adding an href='#'
attribute and removing it.

re: IE6 memory leak - very fiddly

kit.ludwick wrote:Of course not. Read RFC3986.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

re: IE6 memory leak - very fiddly

Daniel Orner wrote:Find a better server. aioe.org is, due to its lack of policy, a home for
spammers and trolls to begin with, and filtered by some people and servers
because of this.
Chances are something else happens than posted here. Not all event
listeners are obvious from the markup. In fact, some people, particularly
clueless authors and users of libraries, like to obfuscate their
applications by using scripting methods to add event listeners when there is
no need for that, calling such atrocities "Unobtrusive JavaScript" then.
Makes it a PITA to debug the application every time.

Then again, IE 6 is a piece of outdated junk. I'm looking forward to its
end-of-life.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

re: IE6 memory leak - very fiddly

Thomas 'PointedEars' Lahn wrote:Can't argue there. -_- It'll be quite a while though, especially in my
line of work.
I have a cleanup function that runs and gets rid of the event handlers
on page unload. I've also installed the latest IE patch (April 2008)
that *supposedly* renders those issues moot.
There certainly is more stuff happening on navigation, but I'm more
concerned about the difference in behavior from adding the href='#' and
leaving it out... if I could understand that maybe I could mimic that
behavior in the real app.
In any case, I'm not doing anything with those tags other than what's
hardcoded in them plus removing the event handlers on page unload. So
unless the Prototype library manually seeks out every tag on the page
and does stuff to them (which I highly doubt) that wouldn't have
anything to do with it.

Thanks for your feedback!

--Daniel

re: IE6 memory leak - very fiddly

Daniel Orner wrote:Prototype.js is junk, and an example of the libaries I mentioned above, so
all bets are off. Dump it and a lot of problems will go away.

Please trim your quotes.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

re: IE6 memory leak - very fiddly

Thomas 'PointedEars' Lahn wrote:Thanks for the tip. I did look at the quotes but thought that they were
all relevant to my reply.
Unfortunately, getting rid of Prototype will be difficult at this
point. Even if Prototype was the culprit, however, that still doesn't
answer the question of why the leak doesn't happen when I add that
"href" attribute to the link. That's what I'm most concerned about.

re: IE6 memory leak - very fiddly

On Nov 19, 5:38*pm, Daniel Orner <dor...@ca.ibm.comwrote:See what you did? Great way to save time.
Why?

re: IE6 memory leak - very fiddly

Daniel Orner wrote:
A webpage that keeps in the memory for days/weeks, should preferably
use scarce client side scripting.
Your code is the same as:

<a href="testPage2.html" target="xx">CLICK ME</a>

If you need additional code in your 'navigate()'-function, it could be
placed in an 'onLoad'-event of the body of testPage2.html, or
alternatively in an 'onClick'-event of the same <a>:

<a href="testPage2.html" target="xx" onClick="...">CLICK ME</a>

The 'onLoad' is maybe better because it is a fresh page. And I like
onClick more than onMouseDown, but that is probably a personal
preference nowadays.
The reason for the leak is impossible to determine, as it is MSIE
source code. My best bet goes to MS coders who assumed that there will
always be a href-attribute if an <a>-tag holds an onMouseDown, and
they overlooked the possibility if that were different.

Microsoft's JScript knows the unofficial and undocumented
'CollectGarbage()'. Maybe it could help in this case, but it's better
to avoid it when possible.
http://groups.google.com/group/comp....3c7c11f20ad185

In your type of application (Kiosk), I suppose you should have the
possibility to update to MSIE 7/8. That could maybe solve the problem
as well.

Anyway, your posted code is a bit unusual and awkward IMHO. I would
rewrite it.

Hope this helps,

--
Bart

re: IE6 memory leak - very fiddly

David Mark wrote:<SNIP>Because if I could isolate that behavior and somehow apply it to my
other tags, it would immediately fix the problem without forcing me to
go back and totally redo half my code. There are parts of Prototype I
use extensively which would be very hard to do without.

re: IE6 memory leak - very fiddly

Bart Van der Donck wrote:Unfortunately it's difficult to work around that while still doing
browser-based apps. Part of the problem is trying to balance the
necessity of contacting the server with the complexity of the client code.
ME[/a]I thought "target" indicated which window frame to click into? How is
that the same as my code? And which one is the same as that? The one
that does leak or the one that doesn't?What's the difference between onmousedown and onClick? I'm not sure I
get this.
onClick is unfortunately not usable in a kiosk environment with a touch
screen where inadvertent mouse drags might mess it up.
I don't think that's the issue... we do long-running tests and
doubtless the garbage collection happens at least at the end of it. I'll
give it a try though... thanks for the tip.
Unfortunately we don't own the kiosks and can't demand this of the
operators.
The posted code is a very simple test; it isn't what we'd actually use.
I'm just trying to analyze it, particularly why that "href='#'" suddenly
causes the leak to go away.

Thanks very much for the help!

re: IE6 memory leak - very fiddly

Daniel Orner wrote:
It is identical to the three (I assume that your 'navigate()' modifies
the location of another frame).

The target-attribute specifies in which frame or window the link
should be opened.

Suppose your page has 2 frames, one <frame name="upperframe"
src="1.htm"and the other <frame name="lowerframe" src="2.htm">, then
a line <a href="3.htm" target="lowerframe">click</ainside the upper
frame will open in the lower frame. The content of upper frame remains
identical in this case, unless, for example, 3.htm holds a <body
onLoad=""with an instruction to alter the location of the upper
frame.
'onClick' has stronger historical roots, but I think it actually
doesn't matter.
I see. Then you can of course not use 'onClick'.
You're welcome. But I doubt if it will help.

--
Bart

re: IE6 memory leak - very fiddly

Daniel Orner wrote:This is a long shot. And shoot me down, but possibly what is happening
is that a succession of windows opening in different targets are causing
an excessive amount of window objects to build up in the browser.
Windows that are closed, are not 'destroyed', merely *marked as closed*.
I try to always re-use window targets for this reason, and to also not
proliferate too many popups

re: IE6 memory leak - very fiddly

On Nov 20, 6:49*pm, The Natural Philosopher <a...@b.cwrote:

[snip]
No.

re: IE6 memory leak - very fiddly

Daniel Orner wrote:Which tip? (See?)
To begin with, how is my signature relevant to your reply? You have posted
without using /dev/brain, period. And you did it again.

And even if all of the quoted text is relevant, it is allowed, and asked
for, to [summarize] the quotation in keeping with its meaning so as to ease
reading.

Read the FAQ. <http://jibbering.com/faq/#posting>
No, it won't. Unless you did not know what you were doing in the first
place, of course, in which case you would get what you deserve.
Bad code does bad things. No doubt about that.
Yes, it would. Prototype.js uses a lot of closures which create circular
references, many of them unnecessary, which are known to leak memory in IE
if host objects (here: DOM objects) are involved (because its GC can't
handle that), and it does not clean up after itself. Adding the `href'
attribute to the `a' element makes it a link in the first place, so that its
corresponding object shows up in the document.links NodeList, for example.

Read the FAQ Notes. <http://jibbering.com/faq/faq_notes/closures.html#clMem>


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

re: IE6 memory leak - very fiddly

The Natural Philosopher wrote:No, I'm not using any popups nor opening windows. Thanks for the
attempt though. 8-)

re: IE6 memory leak - very fiddly

Thomas 'PointedEars' Lahn wrote:
<snip>This sounds promising... however, it seems to work backwards from my
understanding. I thought that the memory leak happens when a DOM node
has a circular reference to a JavaScript object. You seem to be saying
that when a link is created, it's added to document.links... wouldn't
that then mean that the link would have *more* references than non-links
and hence be *more* likely to leak, rather than stop leaking? Or is
there something I'm not understanding properly?
Thanks for your help.

re: IE6 memory leak - very fiddly

Thomas 'PointedEars' Lahn wrote:Thanks for your continuing help with this, and apologies for my newness
to the rules of this newsgroup. Doubtless I'll stumble again, so your
patience is appreciated.
Maybe I'm being dense, but I still think I'm missing something. Your
explanation seems to indicate that when the tag in question is a link,
that something in the library might add an event to the document.links
list, and that event would leak. However, I'm seeing the opposite - when
the tag is a link, it *doesn't* leak. It's only when it isn't a link
that the leak occurs.
Something else occurred to me, too... doesn't IE6 have a document.all
NodeList in any case? So why would it matter if it's a link or not?
I double-checked the Prototype source code and the word "link" doesn't
occur anywhere inside it, so it isn't doing anything with document.links
(and neither am I)...