On 06/28/2011 03:36 PM, Anne van Kesteren wrote:
On Tue, 28 Jun 2011 13:30:09 +0200, Olli Pettay
<olli.pet...@helsinki.fi> wrote:
There is now a patch for Gecko to implement a variant of this
proposal https://bugzilla.mozilla.org/show_bug.cgi?id=641821
The patch adds the following methods (with moz prefix) to Node
(I assume Attr will not extend Node in the near future)
void addAttributeChangedListener(in MutationCallback aCallback);
void addChildlistChangedListener(in MutationCallback aCallback);
void addTextDataChangedListener(in MutationCallback aCallback);
void removeAttributeChangedListener(in MutationCallback aCallback);
void removeChildlistChangedListener(in MutationCallback aCallback);
void removeTextDataChangedListener(in MutationCallback aCallback);
[Callback, NoInterfaceObject]
interface MutationCallback
{
// aNode is the node to which the listener was added.
// aChangeTarget is the node in which the mutation was made.
void handleMutation(in Node aNode, in Node aChangeTarget);
};
The changes to Jonas' proposal are merging non-Subtree methods to
xxxSubtreexxx methods and adding aChangeTarget to the callback.
The basic idea behind the API is to have something simple, yet powerful.
Script libraries could add all sorts of filtering above the low level
API.
Comments?
I have a question. Given
removeNode(...)
teehee()
will teehee() be executed after any relevant listeners have been invoked
or before?
teehee() would be executed after relevant callbacks have been invoked.
That is, are listeners run while the removeNode() has not yet
returned? And if so, is the problem with the original mutation events
avoided because the node being removed is not exposed to the listeners?
The problem with the original mutation events is avoided because the
callbacks are called at "safe" time. Right before the method returns,
but after all the mutations are done. So the DOM is at stable state when
callbacks runs.
-Olli
Also, thanks for working on this!
Cheers,
