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

On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa <rniwa@webkit.org> wrote:

> On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafaelw@google.com>
>> wrote:
>> > I too thought we had intentionally spec'd them to not fire during load.
>> >
>> > The HTML spec is clear about this WRT Mutation Events:
>> >
>> > http://www.whatwg.org/specs/web-apps/current-work/#tree-construction:
>> >
>> > "DOM mutation events must not fire for changes caused by the UA
>> > parsing the document. (Conceptually, the parser is not mutating the
>> > DOM, it is constructing it.) This includes the parsing of any content
>> > inserted using document.write() and document.writeln() calls."
>> >
>> > It seems like this should also apply to Mutation Observers, unless we
>> > have compelling reasons to do otherwise.
>>
>> This was something that we got people complaining about with mutation
>> events over the years. Our answer used to be that mutation events
>> generally suck and you can't depend on them anyway. Obviously not an
>> argument we'd want to use for MutationObservers.
>>
>> I can't think of any cases where you would *not* want these to fire
>> for parser mutations.
>>
>
> Agreed. I'm in favor of observers being notified for parser-initiated DOM
> mutations. The primary reason we don't fire mutation events for parser
> insertion & removal is because they're synchronous and introduces all sorts
> of problems including security vulnerabilities but that isn't the case with
> mutation observers.
>
> One question. Should we also notify mutation observers immediately before
> executing synchronous scripts (i.e. script elements without differ or async
> content attributes) to address Mihai's use case?
>

This is one part of a more general question (raised by Ojan on
webkit.org/b/89351): what should the timing be for delivery of these
parser-initiated mutations? Mihai's use case is one example where we might
want something other than end-of-task delivery. Ojan points out that simply
using end-of-task could expose low-level implementation detail of the
parser to script (such as how much parsing is done in a single task before
the parser yields).

Does Firefox do anything special here? Or does it simply use the same
end-of-task delivery as everywhere else?

- Adam