On 06/19/2012 11:37 PM, Adam Klein wrote:
On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa <rn...@webkit.org
On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jo...@sicking.cc
On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafa...@google.com
> I too thought we had intentionally spec'd them to not fire during
> The HTML spec is clear about this WRT Mutation Events:
> "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.