IE6 memory leak - very fiddly

[Daniel Orner]

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

 

[kit.ludwick]

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...

 

[Daniel Orner]

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...

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.

 

[Thomas 'PointedEars' Lahn]

Wouldn't the "location.href='#'" reload the page, [...]

Of course not. Read RFC3986.


PointedEars

 

[Thomas 'PointedEars' Lahn]

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):

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.

[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?

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

 

[Daniel Orner]

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):

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.

[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?

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

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

 

[Thomas 'PointedEars' Lahn]

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?

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.
[...]

[...]
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.

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

 

[Daniel Orner]

Daniel Orner wrote:
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?
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.
[...]

[...]
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.

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

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.

 

[David Mark]

Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
     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 themass of
code that gets executed on page load/unload?
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.
[...]
[...]
       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.

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

        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 difficultat this
point. Even if Prototype was the culprit, however, that still doesn't

See what you did? Great way to save time.

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.

Why?

 

[Bart Van der Donck]

     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.

A webpage that keeps in the memory for days/weeks, should preferably
use scarce client side scripting.

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]

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.

     Does anyone have any clue why this might be, ignoring the massof
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?

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.lang.javascript/msg/fe3c7c11f20ad185

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,

 

[Daniel Orner]

Daniel Orner wrote:
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
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?

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.

Why?

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.

 

[Daniel Orner]

A webpage that keeps in the memory for days/weeks, should preferably
use scarce client side scripting.

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.

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]

Your code is the same as:

[a href="testPage2.html" target="xx"]CLICK 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?

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]

What's the difference between onmousedown and onClick? I'm not sure I
get this.

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.

onClick is unfortunately not usable in a kiosk environment with a touch
screen where inadvertent mouse drags might mess it up.

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?

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.lang.javascript/msg/fe3c7c11f20ad185

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.

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.

Unfortunately we don't own the kiosks and can't demand this of the
operators.

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

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!

 

[Bart Van der Donck]

Daniel Orner wrote:

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

Your code is the same as:
  [a href="testPage2.html" target="xx"]CLICK 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?

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</a> inside 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.

  [a href="testPage2.html" target="xx" onClick="..."]CLICK ME[/a]

       What's the difference between onmousedown and onClick? I'mnot sure I
get this.

'onClick' has stronger historical roots, but I think it actually
doesn't matter.

 > 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.

        onClick is unfortunately not usable in a kiosk environment with a touch
screen where inadvertent mouse drags might mess it up.

I see. Then you can of course not use 'onClick'.

        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.

You're welcome. But I doubt if it will help.

 

[The Natural Philosopher]

Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
Thomas 'PointedEars' Lahn wrote:
Daniel Orner wrote:
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?

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.

Why?

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.

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

 

[David Mark]

[snip]

This is a long shot. And shoot me down, but possibly what is happening

No.

 

[Thomas 'PointedEars' Lahn]

Thanks for the tip.

Which tip? (See?)

I did look at the quotes but thought that they were all relevant to my
reply.

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.

Unfortunately, getting rid of Prototype will be difficult at this point.

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.

Even if Prototype was the culprit,

Bad code does bad things. No doubt about that.

however, that still doesn't answer the question of why the leak doesn't
happen when I add that "href" attribute to the link.

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

 

[Daniel Orner]

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?

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.

Why?

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.

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

No, I'm not using any popups nor opening windows. Thanks for the
attempt though.

 

[Daniel Orner]

Thomas 'PointedEars' Lahn wrote:

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>

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.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
<snip>

Sigh. [psf 10.1]

You should not simply snip what is being referred to in the quoted text, in
order to preserve the context of what you quoted, of course. (Snipping is
only indicated if what you snipped is not relevant to the reply at all.) If
the target of the reference is too large to be quoted, you should summarize
it or only quote the parts of it that are actually relevant, while marking
omissions. In this case, you should have left in

so that

would have made sense to the non-regular reader without having to look up
the precursor (that may not be available anymore then).

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>

[...] 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?

Chances are that Prototype.js uses document.links or a similar NodeList in a
closure and adds event listeners with scripting. The uncleaned circular
references to the NodeList or an element of that list would leak memory in
IE. That effect could then only be observed if the event target results in
an element of such a NodeList, i.e. if you make that possible by adding the
`href' attribute.

This is nothing but conjecture, of course. Only a look at the source code
can provide a definitive answer.


PointedEars

 

[Daniel Orner]

Thomas 'PointedEars' Lahn wrote:

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>

[...] 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?

Chances are that Prototype.js uses document.links or a similar NodeList in a
closure and adds event listeners with scripting. The uncleaned circular
references to the NodeList or an element of that list would leak memory in
IE. That effect could then only be observed if the event target results in
an element of such a NodeList, i.e. if you make that possible by adding the
`href' attribute.

This is nothing but conjecture, of course. Only a look at the source code
can provide a definitive answer.

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)...