Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: Peter Michaux <petermichaux@xxxxxxxxx>
- Date: Sun, 17 Feb 2008 23:05:35 -0800 (PST)
On Feb 17, 10:55 pm, David Mark <dmark.cins...@xxxxxxxxx> wrote:
On Feb 18, 1:31 am, Peter Michaux <petermich...@xxxxxxxxx> wrote:
[snip]
But for IE onunload I'm using detachEvent so the element no longer has
a reference to the functions involved. That should take care of it.
From what I have heard, that doesn't help for elements that have been
removed from the document. I don't understand why it wouldn't help,
but it seems the justification for the "clean" functions that are
called when innerHTML replaces elements. IIRC, your FORK library does
that.
Yes. When I remove or replace elements in the DOM I call the
FORK.purgeElement with the deep flag to remove all listeners.
Perhaps in this case the memory is leaked as soon as the
element is replaced? I really need to run some tests to confirm this
theory.
Regardless, I just don't think it is good practice to create circular
references involving DOM elements in the library's closure.
There is no choice when fixing the execution "this" object of a
handler. The handler has to have the element in it's closure.
I don't think it is a good idea for listeners to remove themselves
during an event.
That is what happens at the end of a drag operation. When the mouseup
event occur both the mousemove and mouseup listeners are removed. At
least that is one way to do it.
Good point. But getting back to the original issue, the "cleanup
queue" grows larger on each drag operation. This should be prevented
by splicing the array when listeners are removed. You should keep
this in mind when you add the code to remove listeners.
It just needs to be done with care. Making a copy of the list of
listeners is how I did it in FORK. The DOM does this also. It is
necessary to determine the possible set of handlers before calling
them. If not and one handler is adding itself to the end of the list
of handlers, it could be an infinite loop.
I would be careful about assuming anything about the window object.
Can it really be expected to receive click events in all (or even
most) implementations?
Before using the Safari workaround I check that
typeof global.onclick == 'object'
The above is true in Safari before any function has been assigned to
global.onclick.
A null value I assume. This seems to be the norm in all but FF.
before anything has been assigned to global.onclick. When a function
is assigned the typeof value is 'function'. That is true in at least
safari so it is a safe bet that the event will bubble up to the
window.
Makes sense.
Peter
.
- Follow-Ups:
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: David Mark
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- References:
- RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: Peter Michaux
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: Peter Michaux
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: David Mark
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: Peter Michaux
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: David Mark
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: Peter Michaux
- Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- From: David Mark
- RFC: Building the Perfect Tabbed Pane (an tutorial article)
- Prev by Date: Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- Next by Date: Re: Starting to Build a JavaScript Library
- Previous by thread: Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- Next by thread: Re: RFC: Building the Perfect Tabbed Pane (an tutorial article)
- Index(es):
Relevant Pages
|
Loading