Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Re: Black-box equivalence of parsing fragments directly into context node

1 view
Skip to first unread message

Henri Sivonen

unread,
Nov 27, 2008, 11:37:55 AM11/27/08
to
(Continuing from public-html.)

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/

Boris Zbarsky

unread,
Nov 27, 2008, 12:41:10 PM11/27/08
to
Henri Sivonen wrote:
> 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.

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

Jonas Sicking

unread,
Dec 1, 2008, 7:10:07 PM12/1/08
to

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

0 new messages