On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa <rn...@webkit.org> wrote:
> On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking <jo...@sicking.cc> wrote: > >> On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein <rafa...@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