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

On 06/19/2012 11:37 PM, Adam Klein wrote:
> On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa <rniwa@webkit.org <mailto:rniwa@webkit.org>> wrote:
>
>     On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jonas@sicking.cc <mailto:jonas@sicking.cc>> wrote:
>
>         On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafaelw@google.com <mailto: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 <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 stuff.


  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

Received on Tuesday, 19 June 2012 20:52:52 UTC