Drip: application to help find memory leaks in IE

riftdesign · 2005-06-03 11:12:24

http://jgwebber.blogspot.com/2005/05/dr … ector.html

I saw this on slashdot today and thought it might help in detecting more memory leaks in xinha.

gogo · 2005-06-03 23:09:43

Mmmm, interesting, I'm almost scared to run it

gogo · 2005-06-03 23:33:17

Lots and lots of leaks. Plenty in the toolbar as I thought might be the case, but also a large number elsewhere.

Foxx · 2005-06-04 05:06:29

I know this has been discussed before (the whole closures discussion), but are some of these leaks fixable? and what effect would that have on Xinha? Would it also improve loading times in IE? Or just prevent IE from crashing when you reload your page?

gogo · 2005-06-04 16:46:29

Wll, it would prevent IE from eating 10 meg per page load. But I honestly dont' know if it's remotely realistic to try and fix it, I suspect not, I don't even know where to begin.

Lets not forget that this is a bug in IE, not Xinha. We do everything right, it's IE that leaks memory like a sieve.

mokhet · 2005-06-06 15:48:45

I think there's a moment where it's better to give up trying to find a solution for IE, i dont think we can do anything about it. For instance, try the tool (drip) on this page http://mokhet.com/x.html

it is an iframe calling a page y.html, which contains just nothing. No javascript, just an empty iframe, the memory usage keep increase. Well of course all this memory loose is far from by understanding, but if IE is not able to open and close a document with an iframe without having memory issues, well, sounds hard to fix.

x.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>title</title>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body>
<iframe src="y.html"></iframe>
</body>
</html>

y.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title></title>
</head>
<body>
Y
</body>
</html>

Siriuss[FN] · 2005-06-07 06:27:45

afaik i just remoove/replacewithsomethingelse the

"htmlarea.css"

.htmlarea .toolbar .buttonDisabled img {
filter: gray() alpha(opacity = 25);
-moz-opacity: 0.25;
}

and memory leak is way smaller.

cos all my projects i use htmlarea is used only in IE, no client knows mozilla products

well, i hope, in next 10 years ie will be made a lil beter.

Last edited by Siriuss[FN] (2005-06-07 06:29:46)

gogo · 2005-06-10 03:40:37

Interesting

Stanislas Rolland · 2005-08-05 15:28:10

Hi,

In September 2004, since there was so many bugs and apparently no one maintaining the code, I started to develop a fork of htmlArea for integration with the TYPO3 CMS (http://typo3.org/extensions/repository/ … ehtmlarea/).

I was recently able to fix the memory leakage problem in this fork of htmlArea.

The main actions that I had to take are the following:

1. On unload, remove all event handlers; using Event Cache helps, especially for the events set by plugins (http://novemberborn.net/javascript/event-cache); nullify event handlers, including the XMLHTTP onreadystatechange handlers; do the same on context menu unload;

2. On unload, nullify all references from DOM elements to JavaScript objects: they are mainly in the tool bar, in the status bar and in the context menu;

3. Eliminate all non-essential anonymous function definitions, especially in the tool bar construction, and including in setTimeout's; follow the guidelines of http://jibbering.com/faq/faq_notes/closures.html;

4. A last one, rather strange, I found when growing desperate: in IE, do not attach events on document; attach them to document.body.

You may experience the result on this page: http://www.fructifor.com/677.html?&L=2

Unfortunately, the resulting code is not readily usable in Xinha, because of some aspects of the TYPO3 integration. However, it is open to inspection on SourceForge: http://cvs.sourceforge.net/viewcvs.py/t … _htmlarea/

Best regards,
Stanislas Rolland

Last edited by Stanislas Rolland (2005-08-05 15:30:41)

gogo · 2005-08-06 01:06:20

Thanks Stanislas, somebody posted about your work a while back. The work I've done on this is mostly in the same areas, mostly in the toolbar as you point out. There's one leak I can't seem to figure out though - <script> elements are leaking, even though I completly nullify everything on them.. any ideas?

Stanislas Rolland · 2005-08-06 10:27:49

Sorry, I don't know about leaking script elements because I don't use them anymore. I have modified the loading of scripts so that all scripts are loaded with XMLHttp requests. I think this is also necessary for Safari support.

Regards,
Stanislas Rolland

gogo · 2005-08-06 23:30:35

Stanislas Rolland wrote:

Sorry, I don't know about leaking script elements because I don't use them anymore. I have modified the loading of scripts so that all scripts are loaded with XMLHttp requests. I think this is also necessary for Safari support.
Regards,
Stanislas Rolland

I looked at doing that, but I couldn't figure a way to eval the loaded javascript in the global scope. Did you come up with a different solution?

Stanislas Rolland · 2005-08-07 02:38:30

I simply do: eval(HTMLArea._request[i].responseText);

where HTMLArea._request[i] is the asynchronous XMLHttp request for the ith script.

Works fine in all browsers for loading plugins and/or browser-specific components, if you have ie and gecko-specific functions in separate js files.

Last edited by Stanislas Rolland (2005-08-07 02:39:02)

gogo · 2005-08-07 21:36:51

But what scope is the eval called in? eg.. if you do

function mycallback()
{
eval(HTMLArea._request[i].responseText);
}

then any functions defined in responseText which were intended to be global, are now only defined within mycallback. N'est pas?

Stanislas Rolland · 2005-08-08 01:15:38

It depends. If you have in the responseText, for example,

function ContextMenu(editor) { ... }

the function will be defined only locally. But if you have

ContextMenu = function(editor) { ... };

then the function ContextMenu is globally available.

It is true that HTMLArea plugins were generally not defined this way. But this is a simple change to make.

You can even have a responseText that contains

HTMLArea.prototype.someFunction = function() { ... browser-specific variant of this someFunction ... };

which could extend your HTMLArea object definition with browser-specific functions.

riftdesign · 2005-09-04 01:22:06

Just saw this on Planet Mozilla:
http://brian.kingsonline.net/talk/index.php/archives/79

It's regarding finding memory leaks in Firefox/Mozilla as an extension. Not sure if this would help.

Xinha Discussion Forum

Announcement

#1 2005-06-03 11:12:24

Drip: application to help find memory leaks in IE

#2 2005-06-03 23:09:43

Re: Drip: application to help find memory leaks in IE

#3 2005-06-03 23:33:17

Re: Drip: application to help find memory leaks in IE

#4 2005-06-04 05:06:29

Re: Drip: application to help find memory leaks in IE

#5 2005-06-04 16:46:29

Re: Drip: application to help find memory leaks in IE

#6 2005-06-06 15:48:45

Re: Drip: application to help find memory leaks in IE

#7 2005-06-07 06:27:45

Re: Drip: application to help find memory leaks in IE

#8 2005-06-10 03:40:37

Re: Drip: application to help find memory leaks in IE

#9 2005-08-05 15:28:10

Re: Drip: application to help find memory leaks in IE

#10 2005-08-06 01:06:20

Re: Drip: application to help find memory leaks in IE

#11 2005-08-06 10:27:49

Re: Drip: application to help find memory leaks in IE

#12 2005-08-06 23:30:35

Re: Drip: application to help find memory leaks in IE

#13 2005-08-07 02:38:30

Re: Drip: application to help find memory leaks in IE

#14 2005-08-07 21:36:51

Re: Drip: application to help find memory leaks in IE

#15 2005-08-08 01:15:38

Re: Drip: application to help find memory leaks in IE

#16 2005-09-04 01:22:06

Re: Drip: application to help find memory leaks in IE

Board footer