Re: Should MutationObservers be able to observe work done by the HTML parser?

On Fri, Jun 29, 2012 at 8:25 PM, Adam Klein <adamk@chromium.org> wrote:
> On Fri, Jun 29, 2012 at 2:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> All in all I think that as soon as we introduce exceptions to when
>> MutationObserver callbacks fire we change the API from being a
>> reliable way to track DOM mutations to a unreliable way where all
>> callers have to be aware of exceptions and deal with them in other
>> ways. I.e. it feels like it significantly reduces the value of
>> MutationObservers.
>>
>> And so far I don't see any good arguments made for making that
>> reduction in value. Did I miss any arguments other then the randomness
>> argument?
>
>
> Performance was one concern that's come up in discussing this with Ojan and
> Rafael. Imagine a MutationObserver attached to the document near the top of
> the page. Now we need to create basically one MutationRecord per node
> inserted (because the parser operates in a depth-first sort of order). I'm
> not at all sure this is a show-stopper (we might be able to introduce some
> new MutationRecord type that could compactly represent parser-style
> operation), but it definitely seems worrisome, especially given that one of
> the common uses for MutationObservers is extensions which might run on many
> (all?) pages.

Hmm.. is there actually anything requiring that nodes are inserted one
at a time? Internally in mozilla we do insert nodes one at a time, but
the notifications we send out to the various subsystems make it seem
like nodes are inserted in big chunks. This has previously been to
give us good performance from the layout engine which benefits from
getting notified by large chunks being inserted rather than nodes
being inserted one at a time. The MutationObserver implementation
hangs off of the same notification system and thus also sees nodes as
being inserted in big chunks.

/ Jonas

Received on Saturday, 30 June 2012 01:15:02 UTC