On 06/19/2012 11:37 PM, Adam Klein wrote:
On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa <rn...@webkit.org 
<mailto:rn...@webkit.org>> wrote:

    On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jo...@sicking.cc 
<mailto:jo...@sicking.cc>> wrote:

        On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafa...@google.com 
<mailto:rafa...@google.com>> wrote:
         > I too thought we had intentionally spec'd them to not fire during 
         > 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 
<http://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.
Mihai's use case is related to 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17529 (where I think Gecko's 
behavior is the good one)
If we start to call mutation callbacks right before script execution, we would 
need to handle cases when
script element is moved in the DOM right before script execution etc. Ugly 

 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?

end-of-microtask or end-of-task everywhere. And yes, some parsing / networking 
details may unfortunately be exposed,
but in a way which should be quite random. Web devs just can't really rely on 
network packages to be delivered to parser in
some exact way.

- Adam

Reply via email to