Here's an updated patch:
@@ -667,13 +667,15 @@
// These three methods are called by the image pool
LzSprite.prototype.__destroyImage = function (img) {
- if (img.sizer) {
+ if (LzSprite.prototype.quirks.ie_alpha_image_loader && img.sizer) {
+ if (img.sizer.tId) clearTimeout(img.sizer.tId);
LzSprite.prototype.__discardElement(img.sizer);
img.sizer.onload = null;
img.sizer.onloadforeal = null;
img.sizer = null;
}
if (img) LzSprite.prototype.__discardElement(img);
+ img = null;
}
LzSprite.prototype.__gotImage = function(url) {
@@ -699,7 +701,7 @@
im.sizer.onload = function() {
im.style.display = '';
// This resolves all sorts of timing-related image
loading bugs- setTimeout(this.onloadforeal, 1);
+ im.sizer.tId = setTimeout(this.onloadforeal, 1);
}
im.sizer.onloadforeal = function() {
im.owner.__imgonload(im.sizer);
-Max
Max Carlson wrote:
Ah, right. Here's a patch that does that:
@@ -667,12 +668,13 @@
// These three methods are called by the image pool
LzSprite.prototype.__destroyImage = function (img) {
- if (img.sizer) {
- LzSprite.prototype.__discardElement(img.sizer);
+ if (LzSprite.prototype.quirks.ie_alpha_image_loader && im.sizer) {
+ if (im.sizer.tId) im.sizer.clearTimeout(im.sizer.tId);
img.sizer.onload = null;
img.sizer.onloadforeal = null;
img.sizer = null;
- }
+ LzSprite.prototype.__discardElement(img.sizer);
+ }
if (img) LzSprite.prototype.__discardElement(img);
}
@@ -699,7 +701,7 @@
im.sizer.onload = function() {
im.style.display = '';
// This resolves all sorts of timing-related image
loading bugs- setTimeout(this.onloadforeal, 1);
+ im.sizer.tId = setTimeout(this.onloadforeal, 1);
}
im.sizer.onloadforeal = function() {
im.owner.__imgonload(im.sizer);
-Max
P T Withington wrote:
That was my point. If the sprite is starting timer callbacks that are
associated with something that could be destroyed, the destroy needs
to remove those callbacks otherwise you risk a runtime error or memory
leak (the callback could easily do something like resurrect the object
that you think your destroyed -- this is a very common source of
event-based leaks).
On 2006-11-03, at 13:40 EST, Philip Romanik wrote:
This didn't help. Looks like the timer needs a call to clearTimeout()
in order to kill the callback.
Perhaps we aren't doing a thorough enough job destroying images when
destroy() is called. If this change does the job I'd prefer it:
LzSprite.prototype.destroy = function(recursive) {
...
if (this.__LZimg) {
LzSprite.prototype.__destroyImage(this.__LZimg);
}
...
}
It would be better to prevent the event from firing if at all possible.
Let me know if this works!
-Max
Philip Romanik wrote:
> Hi Max.
>
> Here's the contents of apply.sh:
>
> patch -bu -p0 <<"EOF"
> Index: WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js
> ===================================================================
> --- WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js (revision 2383)
> +++ WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js (working copy)
> @@ -702,7 +702,9 @@
> setTimeout(this.onloadforeal, 1);
> }
> im.sizer.onloadforeal = function() {
> - im.owner.__imgonload(im.sizer);
> + if (im.owner && im.sizer) { // Discarded by
> __destroyImage?
> + im.owner.__imgonload(im.sizer);
> + }
> }
> im.sizer.src = url;
> }
> EOF
>
>> Hi Phil,
>>
>> I can't seem to download the patch file - even after removing the
>> trailing backslash. Can you send it again? Thanks!
>>
>> -Max
>
>
