Leaky Version of JScript

[Garrett Smith]

Microsoft patched a leak issue in IE6 as IE6 SP2.

I want provide a "clean up" function to remove event listeners onunload,
but only for the known leaky version of jscript/IE.

Is it possible to detect this?

It is possible to detect versions of jscript with conditional comments:-

var isLeak/*@cc_on=(@_jscript_version<=5.6 && @_jscript_build < 8820)@*/;

if(isLeak){
// add cleanUp function onunload.
}

Garrett

 

[David Mark]

Microsoft patched a leak issue in IE6 as IE6 SP2.

I want provide a "clean up" function to remove event listeners onunload,
but only for the known leaky version of jscript/IE.

Who cares?

Is it possible to detect this?
Again.


It is possible to detect versions of jscript with conditional comments:-

var isLeak/*@cc_on=(@_jscript_version<=5.6 && @_jscript_build < 8820)@*/;

if(isLeak){
   // add cleanUp function onunload.

}

Don't use patterns that leak and you won't have to worry about
cleaning up. I'm starting to think this message will never sink in.

 

[Pherdnut]

Who cares?







Don't use patterns that leak and you won't have to worry about
cleaning up.  I'm starting to think this message will never sink in.

I seriously think it's time to let IE 6 go. It's primarily the IT
departments of corporations that are afraid to upgrade for fear of
things breaking that are the real culprit anyway. They're not going to
budge until navigating the web with IE 6 becomes even more difficult
than it already is and for that to happen we need to stop supporting
it unconditionally. Not that we have any say in the matter.

But seriously, it's half as old as the world wide web. It's still
rendering with Mosaic FFS!

 

[Pherdnut]

Sorry, that was an obnoxious answer on my part.

I looked it up in Powell's book. That looks like it would work. He's
got examples where it's all in the comment and you can use conditions
too.

This is untested but from what I'm seeing of the syntax you could
probably do this and let the IE 6 junk be nothing more than a comment
to the other browsers.

/*@cc_on @*/

/*@if (@_jscript_version<=5.6 && @_jscript_build < 8820)
function() { //leak handling code }
@end @*/

I don't really get the thing where he puts the cc_on in comments above
the rest. I guess @cc_on activates checking inside the comments until
a comment is parsed that doesn't begin and end with the @ symbols.

 

[Garrett Smith]

Possibly users of an older version of IE6.

It's 10 lines of code, executed only for these guys. Here:
http://github.com/GarrettS/ape-javascript-library/

under "build/EventPublisher.js".

As is, there is a check:-

I seriously think it's time to let IE 6 go. It's primarily the IT
departments of corporations

Corporations... With millions of dollars. Probably public libraries, too.

Users in those corporations (or library card holders ;-) may *want* an
upgrade, but they might not have that option available.

I'm not saying that IE6 isn't a pile, but I have chosen to support it
because there are still a lot of IE6 users.

And so the questions are:-
1) Is the leak tied to the build of jscript, and if so,
2) can it be detected this way and if not,
3) how can the leaky implementation be identified?

Garrett

 

[Eric Bednarz]

This is untested but from what I'm seeing of the syntax you could
probably do this and let the IE 6 junk be nothing more than a comment
to the other browsers.

/*@cc_on @*/

/*@if (@_jscript_version<=5.6 && @_jscript_build < 8820)

You should better have tested it. The JScript version can be updated
independently from the browser, and that happened automagically for a
lot of users with Windows XP Service Pack 3 (likewise, I have IE 5.5 on
Windows 2000 that got JScript 5.6 as a security update).

I don't really get the thing where he puts the cc_on in comments above
the rest. I guess @cc_on activates checking inside the comments until
a comment is parsed that doesn't begin and end with the @ symbols.

The comment delimiters are what makes compilation conditional for
*other* engines. For IE you could as well just write something like

@cc_on
var fubar = @_jscript_version;

Since the syntax is convulted and rather badly documented you could
better do something like (untested ;-)

var fubar = /*@cc_on @_jscript_version || @*/ null;

if (fubar) {
// ...
}

as long as you rememeber that you test for the JScript version, not the
IE version.

 

[Erik Reppen]

Possibly users of an older version of IE6.

It's 10 lines of code, executed only for these guys.  Here:http://github.com/GarrettS/ape-javascript-library/

under "build/EventPublisher.js".

As is, there is a check:-



Corporations... With millions of dollars. Probably public libraries, too.

Users in those corporations (or library card holders ;-) may *want* an
upgrade, but they might not have that option available.

I'm not saying that IE6 isn't a pile, but I have chosen to support it
because there are still a lot of IE6 users.

And so the questions are:-
1) Is the leak tied to the build of jscript, and if so,
2) can it be detected this way and if not,
3) how can the leaky implementation be identified?

Garrett

http://novemberborn.net/javascript/memory-leaks-gone

Dean Edwards would appear to suggest searching for the absence of
"SV1" in the userAgent string as a semi-reliable method. I haven't
been able to actually find anything resembling a listing of JScript
builds and issues by build number.

http://support.microsoft.com/kb/906294/

This issue results from the patch. I know nothing of these 'monickers'
but if there's any related method or property tied to the java object
stuff that you might be able to test for, it might be a decent
workaround.

 

[Eric Bednarz]

Just for the record:

You should better have tested it. The JScript version can be updated
independently from the browser, and that happened automagically for a
lot of users with Windows XP Service Pack 3 (likewise, I have IE 5.5 on
Windows 2000 that got JScript 5.6 as a security update).

While I knew that off the top of my head, I couldn’t comment on the
jscript_build part from the breakfast table.

My IE6 on Windows XP SP2 with JScript 5.6 at work reports build 8835. So
much for copy and paste engineering.

 

[Erik Reppen]

It's an interesting problem but does it take long enough to dump those
event handlers in IE 6 to be worth filtering a very specific version?

Anyway, based on info here:

http://support.microsoft.com/kb/830555/

I'm not sure how they could have fixed the leak without it being about
the JScript build getting updated.

 

[Thomas 'PointedEars' Lahn]

Microsoft patched a leak issue in IE6 as IE6 SP2.
I want provide a "clean up" function to remove event listeners onunload,
but only for the known leaky version of jscript/IE.
Who cares?

Possibly users of an older version of IE6.

It's 10 lines of code, executed only for these guys. Here:http://github.com/GarrettS/ape-javascript-library/

under "build/EventPublisher.js".

As is, there is a check:-

It is possible to detect versions of jscript with conditional comments:-
var isLeak/*@cc_on=(@_jscript_version<=5.6 && @_jscript_build < 8820)@*/;
if(isLeak){
// add cleanUp function onunload.
}
Don't use patterns that leak and you won't have to worry about
cleaning up. I'm starting to think this message will never sink in.
I seriously think it's time to let IE 6 go. It's primarily the IT
departments of corporations

Corporations... With millions of dollars. Probably public libraries, too.

Users in those corporations (or library card holders ;-) may *want* an
upgrade, but they might not have that option available.

I'm not saying that IE6 isn't a pile, but I have chosen to support it
because there are still a lot of IE6 users.

And so the questions are:-
1) Is the leak tied to the build of jscript, and if so,
2) can it be detected this way and if not,
3) how can the leaky implementation be identified?
[...]

http://novemberborn.net/javascript/memory-leaks-gone

Dean Edwards would appear to suggest searching for the absence of
"SV1" in the userAgent string as a semi-reliable method. [...]

That would emphasize again that Dean Edwards could not be taken seriously
with regard to browser scripting.


PointedEars

 

[Thomas 'PointedEars' Lahn]

You should better have tested it. The JScript version can be updated
independently from the browser, and that happened automagically for a
lot of users with Windows XP Service Pack 3 (likewise, I have IE 5.5 on
Windows 2000 that got JScript 5.6 as a security update).

But isn't this a JScript-related issue, so the JScript (build) version would
be what is relevant and in need of testing (if the problem cannot be solved
differently)? IOW, one must not test for the browser release because there
would be false positives or false negatives then.


PointedEars

 

[Erik Reppen]

But isn't this a JScript-related issue, so the JScript (build) version would
be what is relevant and in need of testing (if the problem cannot be solved
differently)?  IOW, one must not test for the browser release because there
would be false positives or false negatives then.

Yeah, I hope everybody is aware that none of those solutions by
themselves were ideal, but sometimes two of the right conditions can
rule out all other possibilities. Anyway, I was throwing some ideas
out there. Do you have any?

 

[Thomas 'PointedEars' Lahn]

[Thomas 'PointedEars' Lahn wrote:]

But isn't this a JScript-related issue, so the JScript (build) version would
be what is relevant and in need of testing (if the problem cannot be solved
differently)? IOW, one must not test for the browser release because there
would be false positives or false negatives then.

Yeah, I hope everybody is aware that none of those solutions by
themselves were ideal, but sometimes two of the right conditions can
rule out all other possibilities. Anyway, I was throwing some ideas
out there. Do you have any?

Unfortunately, nobody in this thread has provided sufficient information
about the problem, which leaves me with the one reasonable recommendation:
Do not write code that leaks in those versions of JScript.

Please leave in an attribution line for each quotation level.


PointedEars

 

[-TNO-]

Microsoft patched a leak issue in IE6 as IE6 SP2.

I want provide a "clean up" function to remove event listeners onunload,
but only for the known leaky version of jscript/IE.

Why not handle the events more generically so they aren't attached to
many elements in the page?

document.onclick = function(e){
e = e || window.event
var tg = e.target || e.srcElement

if(/* some identifying condition*/){
//lookup event functionality in a lookup table
}
}

 

[David Mark]

Why not handle the events more generically so they aren't attached to
many elements in the page?

document.onclick = function(e){
    e = e || window.event
    var tg = e.target || e.srcElement

    if(/* some identifying condition*/){
        //lookup event functionality in a lookup table
    }

}

That's delegation taken too far. And one listener can leak as well as
many. The solution (as discussed here several times) is to stop
shooting yourself in the foot with patterns that are known to require
"cleanup". That's it. Why people are still trying to diagram an end-
around play at this point is beyond me.

 

[-TNO-]

That's delegation taken too far.  And one listener can leak as well as
many.  The solution (as discussed here several times) is to stop
shooting yourself in the foot with patterns that are known to require
"cleanup".  That's it.  Why people are still trying to diagram an end-
around play at this point is beyond me.

Since I'm a late comer to this list, would you mind humoring me with a
few keywords to search this list for so that I can find these relevant
discussions?

 

[Eric Bednarz]

Eric Bednarz wrote:

This is untested but from what I'm seeing of the syntax you could
probably do this and let the IE 6 junk be nothing more than a comment
to the other browsers. […]
/*@if (@_jscript_version<=5.6 && @_jscript_build < 8820)

You should better have tested it. The JScript version can be updated
independently from the browser, and that happened automagically for a
lot of users with Windows XP Service Pack 3 (likewise, I have IE 5.5 on
Windows 2000 that got JScript 5.6 as a security update).

But isn't this a JScript-related issue, so the JScript (build) version would
be what is relevant and in need of testing (if the problem cannot be solved
differently)?

OK, reading back to Garret’s OP – which I seem to have missed completely
– I misread this as a IE6 sniffing procedure (and it’s used a lot in
that way).

Is there any evidence that the JScript build version is any reliable
source for leak fixing upgrades (as I remember, that was part of a
security update)?

A while ago I posted a link to a simple test page that leaks like a
sieve – depending on source code size and without any circular
references at all – on 2 up to date IE6 XP SP2 installations I can
access (didn’t leak on SP3 or Windows 2000(!), no feedback as far as I
can remember), so I wouldn’t be optimistic about the goal of the OP
either.

 

[Garrett Smith]

Eric Bednarz wrote:

This is untested but from what I'm seeing of the syntax you could
probably do this and let the IE 6 junk be nothing more than a comment
to the other browsers. […]
/*@if (@_jscript_version<=5.6 && @_jscript_build < 8820)
You should better have tested it. The JScript version can be updated
independently from the browser, and that happened automagically for a
lot of users with Windows XP Service Pack 3 (likewise, I have IE 5.5 on
Windows 2000 that got JScript 5.6 as a security update).

Interesting. Don't spill cornflakes on that one.

OK, reading back to Garret’s OP – which I seem to have missed completely
– I misread this as a IE6 sniffing procedure (and it’s used a lot in
that way).

Is there any evidence that the JScript build version is any reliable
source for leak fixing upgrades (as I remember, that was part of a
security update)?

No, AFAIK. I am uncertain but it seems doubtful.

The jscript version came as part of a security update that included a
memory fix. Did the jscript update fixed the memory leak issue? I don't
know.

A while ago I posted a link to a simple test page that leaks like a
sieve – depending on source code size and without any circular
references at all – on 2 up to date IE6 XP SP2 installations I can
access (didn’t leak on SP3 or Windows 2000(!), no feedback as far as I
can remember), so I wouldn’t be optimistic about the goal of the OP
either.

The leak may have been solved from outside of jscript. AIUI (not very
well), IE has multiple garbage collectors.

Using IE Tester, I've not been able to reproduce a closure-based leak.

Either the test is not stressful enough, IE Tester manages memory in a
way that covers up the leak, or I've made a faulty test (below).

The testing strategy has two pages. One page create a circular reference
from a element -> function -> scope -> element. THe second page is just
a link to the first page.

I navigated repeatedly between that page and another page. I noticed a
very slight increase in memory, but that went back down. No significant
leak problem detected.

A better testing strategy may be in order.

closure-leak.html---------------------------------------------------
<!doctype html>
<head>
<title>leak test</title>
</head>
<body>

<script type="text/javascript">
window.onload = function(){
var lis = document.getElementsByTagName("li");

// create a clous
for(var i = 0; i < lis.length; i++) {
var li = lis;

// the li has a function property.
li.onclick = function(ev) {
// the function has the li in scope,
// and just to make sure there was no optimized
// closure, lets access li:
li.title = li.tagName + i;
};
li.onclick = null;
}

};
</script>
<a href="closure-leak-page2.html">page 2</a>
<ul>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
<li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li><li>*</li>
</ul>
</body>
</html>
--------------------------------------------------------------------------------

closure-leak-page2.html
--------------------------------------------------------------------------------
<!doctype html>
<html>
<head>
<title>this page has no script.</title>
</head>
<body>
<a href="closure-leak.html">page 1 (leaky page)</a>
</body>
</html>