By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,562 Members | 1,223 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,562 IT Pros & Developers. It's quick & easy.

Memory Leak IE Javascript attribute add onblur

P: n/a
I posted this originally in the csharp group, but I think that may be
the wrong group. This seems more appropriate:

I'm running into an issue with a memory leak in an Asp.Net web page.

In the code behind (.cs) I'm adding onchange, onblur and onfocus
events to a bunch of objects that reside on my page (textboxes and
dropdownlist).

After using Drip i've found that these are leaving open DOM objects.

Does anybody know how to kill these when I exit the page?

Thank you very much.

some responses:
>Joshua,

For most any browser that has a javascript engine, there is a garbage
collector which will take care of this for you.

Which browser are you working with? If you exit the page, then
eventually, the gc for the javascript engine should eventually clean things
up.

--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com
The javascript engine on the client side in IE
That should not be a problem. Javascript is managed, it means that you don't
have to release the memory.

Are you sure that is the problem?


And my response to them:

I'm using Drip to identify these because the javascript garbage
collector is not taking care of it. After using the page for a while,
entering and exiting, the memory grows so much that they have to close
the browser and reopen it - it grows and does not go down after
exiting the page or even the site. I'm tacking the memory using the
task manager, process tab watching iexplore.exe. I'm using IE 7 (or
6). However the Drip program I saw was suggested by others to
identify open DOM calls (in reference to leaked memory). I'm just not
sure how to kill the open DOM calls. Is there some javascript call
that I can use on the unload to kill these?

The page has some ajax toolkit items (calendar and cascading dropdown)
and makes some web service calls as well.

Oct 3 '07 #1
Share this Question
Share on Google+
9 Replies


P: n/a
On Oct 4, 3:38 pm, Joshua wrote:
On Oct 3, 9:41 am, Henry wrote:
<snip>
>>In the code behind (.cs) I'm adding onchange, onblur and
onfocus events to a bunch of objects that reside on my
page (textboxes and dropdownlist).
>But what your "code behind" is doing is generating HTML and/or
client- side javascript, which is actually doing the work of
adding event handling functions to HTML elements (or causing
that work to be done, but still on the client). You (or
someone who understands it) need to be looking at the HTML
and/or javascript output from your servers and sent to the
browser to be interpreted/rendered/executed there.
>>After using Drip i've found that these are leaving open DOM
objects.
>>Does anybody know how to kill these when I exit the page?
>Yes, but not in any way specific to your code. ...
<snip>
reg:
"reg"?
You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).

Do you know how to do this?
Yes, for code I can understand.
Do i just find the objects on unload and
set them to null?
Objects cannot be set to null. References to objects can be set to
null, and breaking circular chains of references usually involves
setting references to objects to null.
If so how can i find all the objects?
What objects?
Can I write a general recursive function to kill all open
circular references on unload?
Yes, but it is a very bad idea because it is very time consuming to
null all possible object references from all DOM Nodes and ActiveX
objects used (though some XML HTTP request systems would not leave the
request objects exposed so onunload cleanup would not be practical).
It is better to break only the circular references you mad in your
client-side code.

Oct 5 '07 #2

P: n/a
On Oct 5, 10:02 am, Henry <rcornf...@raindrop.co.ukwrote:
On Oct 4, 3:38 pm, Joshua wrote:
On Oct 3, 9:41 am, Henry wrote:
<snip>
>In the code behind (.cs) I'm adding onchange, onblur and
onfocus events to a bunch of objects that reside on my
page (textboxes and dropdownlist).
But what your "code behind" is doing is generating HTML and/or
client- side javascript, which is actually doing the work of
adding event handling functions to HTML elements (or causing
that work to be done, but still on the client). You (or
someone who understands it) need to be looking at the HTML
and/or javascript output from your servers and sent to the
browser to be interpreted/rendered/executed there.
>After using Drip i've found that these are leaving open DOM
objects.
>Does anybody know how to kill these when I exit the page?
Yes, but not in any way specific to your code. ...
<snip>
reg:

"reg"?
You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).
Do you know how to do this?

Yes, for code I can understand.
Do i just find the objects on unload and
set them to null?

Objects cannot be set to null. References to objects can be set to
null, and breaking circular chains of references usually involves
setting references to objects to null.
If so how can i find all the objects?

What objects?
Can I write a general recursive function to kill all open
circular references on unload?

Yes, but it is a very bad idea because it is very time consuming to
null all possible object references from all DOM Nodes and ActiveX
objects used (though some XML HTTP request systems would not leave the
request objects exposed so onunload cleanup would not be practical).
It is better to break only the circular references you mad in your
client-side code.
So how can you identify and kill a circular DOM reference? Any
ideas? Is there a link to something out there to some code samples?

Oct 5 '07 #3

P: n/a
On Oct 5, 1:45 pm, Joshua <joshuafa...@gmail.comwrote:
On Oct 5, 10:02 am, Henry <rcornf...@raindrop.co.ukwrote:
On Oct 4, 3:38 pm, Joshua wrote:
On Oct 3, 9:41 am, Henry wrote:
<snip>
>>In the code behind (.cs) I'm adding onchange, onblur and
>>onfocus events to a bunch of objects that reside on my
>>page (textboxes and dropdownlist).
>But what your "code behind" is doing is generating HTML and/or
>client- side javascript, which is actually doing the work of
>adding event handling functions to HTML elements (or causing
>that work to be done, but still on the client). You (or
>someone who understands it) need to be looking at the HTML
>and/or javascript output from your servers and sent to the
>browser to be interpreted/rendered/executed there.
>>After using Drip i've found that these are leaving open DOM
>>objects.
>>Does anybody know how to kill these when I exit the page?
>Yes, but not in any way specific to your code. ...
<snip>
reg:
"reg"?
You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).
Do you know how to do this?
Yes, for code I can understand.
Do i just find the objects on unload and
set them to null?
Objects cannot be set to null. References to objects can be set to
null, and breaking circular chains of references usually involves
setting references to objects to null.
If so how can i find all the objects?
What objects?
Can I write a general recursive function to kill all open
circular references on unload?
Yes, but it is a very bad idea because it is very time consuming to
null all possible object references from all DOM Nodes and ActiveX
objects used (though some XML HTTP request systems would not leave the
request objects exposed so onunload cleanup would not be practical).
It is better to break only the circular references you mad in your
client-side code.

So how can you identify and kill a circular DOM reference? Any
ideas? Is there a link to something out there to some code samples?
It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.

Ajax is pretty, but always seems to cause more problems than it's
worth.

Oct 11 '07 #4

P: n/a
On Oct 11, 1:30 pm, Joshua <joshuafa...@gmail.comwrote:
On Oct 5, 1:45 pm, Joshua <joshuafa...@gmail.comwrote:


On Oct 5, 10:02 am, Henry <rcornf...@raindrop.co.ukwrote:
On Oct 4, 3:38 pm, Joshua wrote:
On Oct 3, 9:41 am, Henry wrote:
<snip>
>In the code behind (.cs) I'm adding onchange, onblur and
>onfocus events to a bunch of objects that reside on my
>page (textboxes and dropdownlist).
But what your "code behind" is doing is generating HTML and/or
client- side javascript, which is actually doing the work of
adding event handling functions to HTML elements (or causing
that work to be done, but still on the client). You (or
someone who understands it) need to be looking at the HTML
and/or javascript output from your servers and sent to the
browser to be interpreted/rendered/executed there.
>After using Drip i've found that these are leaving open DOM
>objects.
>Does anybody know how to kill these when I exit the page?
Yes, but not in any way specific to your code. ...
<snip>
reg:
"reg"?
You handle the issue by avoiding forming such circular
references or explicitly breaking them when they are no longer
important (as the page unloads at the latest).
Do you know how to do this?
Yes, for code I can understand.
Do i just find the objects on unload and
set them to null?
Objects cannot be set to null. References to objects can be set to
null, and breaking circular chains of references usually involves
setting references to objects to null.
If so how can i find all the objects?
What objects?
Can I write a general recursive function to kill all open
circular references on unload?
Yes, but it is a very bad idea because it is very time consuming to
null all possible object references from all DOM Nodes and ActiveX
objects used (though some XML HTTP request systems would not leave the
request objects exposed so onunload cleanup would not be practical).
It is better to break only the circular references you mad in your
client-side code.
So how can you identify and kill a circular DOM reference? Any
ideas? Is there a link to something out there to some code samples?

It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.
And they don't break them on unload? If not, they are poorly written
widgets and you should stop using them.
>
Ajax is pretty, but always seems to cause more problems than it's
worth.
Your problem has nothing to do with Ajax. You are confusing Ajax with
DOM manipulation.
Oct 12 '07 #5

P: n/a
Joshua said the following on 10/11/2007 1:30 PM:

<snip>
It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.
What "ajax toolkit" are you using though? If removing the toolkit
removes the memory leak, then something in the toolkit is causing it and
if that is true, you need to contact the author of the library to find
out the best way to solve it. The best way to solve it is going to be to
correct it in the library itself.
Ajax is pretty, but always seems to cause more problems than it's
worth.
Ajax may be, and may not be, the direct cause of your problem. The
biggest problem with "AJAX" (an XHR Request) is people not using it for
it's intended purpose.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Oct 12 '07 #6

P: n/a
On Oct 11, 9:49 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
Joshua said the following on 10/11/2007 1:30 PM:

<snip>
It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.

What "ajax toolkit" are you using though? If removing the toolkit
removes the memory leak, then something in the toolkit is causing it and
if that is true, you need to contact the author of the library to find
out the best way to solve it. The best way to solve it is going to be to
correct it in the library itself.
Ajax is pretty, but always seems to cause more problems than it's
worth.

Ajax may be, and may not be, the direct cause of your problem. The
biggest problem with "AJAX" (an XHR Request) is people not using it for
it's intended purpose.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ -http://jibbering.com/faq/index.html
Javascript Best Practices -http://www.JavascriptToolbox.com/bestpractices/
I'm simply using the most recent ajaxtoolkit dll downloaded from the
site as is. I have not made any modifications. This has been brought
up to the author (ms) and they have said that it does not exist.
However, if you use drip or sieve and simply navigate to their sample
web site, navigate to the calendar sample, click the calendar and
select a date, and then navigate away you will see 11 open DOM leaks
(each time you visit the page). And these are not deleted when you
reload, navigate away or unload. They are open DOM leaks that are not
able to be collected by the IE garbage collector until (of course) you
shut down the browser.

Oct 15 '07 #7

P: n/a
Joshua said the following on 10/15/2007 11:49 AM:
On Oct 11, 9:49 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
>Joshua said the following on 10/11/2007 1:30 PM:

<snip>
>>It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.
What "ajax toolkit" are you using though? If removing the toolkit
removes the memory leak, then something in the toolkit is causing it and
if that is true, you need to contact the author of the library to find
out the best way to solve it. The best way to solve it is going to be to
correct it in the library itself.
>>Ajax is pretty, but always seems to cause more problems than it's
worth.
Ajax may be, and may not be, the direct cause of your problem. The
biggest problem with "AJAX" (an XHR Request) is people not using it for
it's intended purpose.
I'm simply using the most recent ajaxtoolkit dll downloaded from the
site as is.
Ummm. What "site" is that? I asked before and you haven't answered.
I have not made any modifications. This has been brought
up to the author (ms) and they have said that it does not exist.
Is ms the author and is that Microsoft or some other ms?

Either way, if the leak exists with the ajaxtoolkit and doesn't exist
without it, then it is obvious that the problem is in the ajaxtoolkit.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Oct 15 '07 #8

P: n/a
On Oct 15, 11:44 am, Randy Webb <HikksNotAtH...@aol.comwrote:
Joshua said the following on 10/15/2007 11:49 AM:
On Oct 11, 9:49 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
Joshua said the following on 10/11/2007 1:30 PM:
<snip>
>It's funny. If I remove all the ajax toolkit items then all the open
DOM leaks go away. The calendar extender and the cascading dropdown
items create circular DOM references.
What "ajax toolkit" are you using though? If removing the toolkit
removes the memory leak, then something in the toolkit is causing it and
if that is true, you need to contact the author of the library to find
out the best way to solve it. The best way to solve it is going to be to
correct it in the library itself.
>Ajax is pretty, but always seems to cause more problems than it's
worth.
Ajax may be, and may not be, the direct cause of your problem. The
biggest problem with "AJAX" (an XHR Request) is people not using it for
it's intended purpose.
I'm simply using the most recent ajaxtoolkit dll downloaded from the
site as is.

Ummm. What "site" is that? I asked before and you haven't answered.
I have not made any modifications. This has been brought
up to the author (ms) and they have said that it does not exist.

Is ms the author and is that Microsoft or some other ms?

Either way, if the leak exists with the ajaxtoolkit and doesn't exist
without it, then it is obvious that the problem is in the ajaxtoolkit.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ -http://jibbering.com/faq/index.html
Javascript Best Practices -http://www.JavascriptToolbox.com/bestpractices/
Try this:

http://asp.net/AJAX/AjaxControlToolk.../Calendar.aspx

Go here (using sieve or drip), click the calendar icon, then navigate
away. That's the only test necessary.

Oct 15 '07 #9

P: n/a
On Oct 15, 6:24 pm, Joshua <joshuafa...@gmail.comwrote:
On Oct 15, 11:44 am, Randy Webb <HikksNotAtH...@aol.comwrote:


Joshua said the following on 10/15/2007 11:49 AM:
On Oct 11, 9:49 pm, Randy Webb <HikksNotAtH...@aol.comwrote:
>Joshua said the following on 10/11/2007 1:30 PM:
><snip>
>>It's funny. If I remove all the ajax toolkit items then all the open
>>DOM leaks go away. The calendar extender and the cascading dropdown
>>items create circular DOM references.
>What "ajax toolkit" are you using though? If removing the toolkit
>removes the memory leak, then something in the toolkit is causing it and
>if that is true, you need to contact the author of the library to find
>out the best way to solve it. The best way to solve it is going to be to
>correct it in the library itself.
>>Ajax is pretty, but always seems to cause more problems than it's
>>worth.
>Ajax may be, and may not be, the direct cause of your problem. The
>biggest problem with "AJAX" (an XHR Request) is people not using it for
>it's intended purpose.
I'm simply using the most recent ajaxtoolkit dll downloaded from the
site as is.
Ummm. What "site" is that? I asked before and you haven't answered.
I have not made any modifications. This has been brought
up to the author (ms) and they have said that it does not exist.
Is ms the author and is that Microsoft or some other ms?
Either way, if the leak exists with the ajaxtoolkit and doesn't exist
without it, then it is obvious that the problem is in the ajaxtoolkit.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ -http://jibbering.com/faq/index.html
Javascript Best Practices -http://www.JavascriptToolbox.com/bestpractices/

Try this:

http://asp.net/AJAX/AjaxControlToolk.../Calendar.aspx
Looked pretty messed up in Windows Safari. Granted it is a Beta, but
I have never seen it render a widget quite this poorly (and I have
tested a lot of widgets on it.) I suspect it will have problems with
other browsers as well. It looked okay in IE7 and FF (though the
keyboard control didn't work in the latter.)
Go here (using sieve or drip), click the calendar icon, then navigate
away. That's the only test necessary.
Not exactly. That drip detector is not infallible. Considering that
Microsoft wrote the script, I suspect at least some of what it
reported is valid.
Oct 15 '07 #10

This discussion thread is closed

Replies have been disabled for this discussion.