On Nov 27, 2008, at 17:13, Boris Zbarsky wrote:
>Henri Sivonen wrote:
>> Well, they'd fire as you insert nodes, yes.
>> Do you mean when the parser inserts node or when a document 
>> fragment is inserted into the context node?
>
> Both, in theory, but if the parser is parsing into an isolated 
> document fragment there won't be any mutation listeners set up 
> anywhere around that yet.
Gecko behaves like HTML5 says here and doesn't fire (script-observable 
at least) mutation events for insertions performed by the parser.
>> I'm doing things like aParent->AppendChildTo(aChild, PR_TRUE); 
>> with the assumption that this notifies but doesn't fire a 
>> mutation event. Now that I've looking further in the code, I'm 
>> suspecting the two might be coupled...
>
> In Gecko, they are.
Do you mean they are coupled when the second argument of AppendChildTo 
is PR_TRUE or that they are coupled in general? They don't appear to be 
coupled in the current parser.
-- 
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
They're coupled in the sense that whenever aNotify is true the 
nsIContent methods will both notify and fire mutation events.  If 
aNotify is false, they will do neither.
In the current parser, the parser does the notifications, not the 
content nodes, so we don't fire mutation events on appends to the tree 
by the parser.  This is by-design.
However, we do (and I think there are pages depending on this; we got 
bug reports when this behavior changed by accident once) fire mutation 
events on innerHTML sets, since those are just a DOM insertBefore on a 
DocumentFragment node.
-Boris
So to be clear.
* We do *not* fire mutation events during 'normal' parsing.
* When setting innerHTML we do *not* fire mutation events during the
   parsing of the new markup.
* When setting innerHTML we *do* fire mutation events when inserting
   the newly parsed subtree into the main document.
All of this is by design (more or less). The first one is partially a 
performance win since we were spending a decent amount of time simply 
checking if we needed to fire mutation events. It was also a security 
win since we didn't need to deal with javascript executing in as many 
places in the parsing code. Some things broke when we made this change, 
but we stuck to it.
I think we want to stick with all of the above. However note that you 
can implement this by parsing directly into the context node with 
aNotify set to false, then manually firing mutation events on the newly 
inserted children.
/ Jonas