- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 10 Sep 2012 05:33:20 -0700
- To: Adam Klein <adamk@chromium.org>
- Cc: Ian Hickson <ian@hixie.ch>, Mihai Parparita <mihaip@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, WebApps WG <public-webapps@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Olli Pettay <Olli.Pettay@helsinki.fi>, Olli@pettay.fi, Rafael Weinstein <rafaelw@chromium.org>
On Fri, Sep 7, 2012 at 12:59 PM, Adam Klein <adamk@chromium.org> wrote: > On Thu, Sep 6, 2012 at 3:51 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Thu, Sep 6, 2012 at 3:14 PM, Adam Klein <adamk@chromium.org> wrote: >> > On Wed, Aug 29, 2012 at 4:05 PM, Ian Hickson <ian@hixie.ch> wrote: >> >> The spec actually does require that the UA "provide a stable state" before >> >> processing <script>s, which invokes the relevant part of the event loop. >> >> If mutation observers were to fire during parse, it would require those to >> >> fire too (it currently does not). >> > >> > In my testing, Gecko doesn't behave this way: MutationRecords are delivered >> > at the end of any encountered <script> tags (at the end-of-microtask, >> > essentially), rather than before they run. If delivery-during-parse is how >> > we end up going, spec-wise, I think it's important for the use-cases that we >> > deliver before each script runs. >> >> Agreed. This sounds like a bug in our implementation. I filed >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=789315 > > As Olli points out on that bug, providing a stable state doesn't > perform a microtask checkpoint (nor invoke > MutationObservers). Given the note attached to the "provide a stable > state" section, "A synchronous section never mutates the DOM, runs any > script, or has any other side-effects", it seems that running observer > callbacks whenever asked to provide a stable state is unlikely to be > the right thing. > > If the HTML parser is updated to enqueue mutations, it seems like > there also needs to be an addition to the steps run when inserting > preparing a <script>, unless Olli and I are missing something. Sorry. I didn't mean to say that the spec was calling for any particular behavior here. What I meant was that I agree that the most sensible behavior would be to flush notifications before and after executing each <script>. Hence I think the spec should call for that behavior, and that implementations should implement that. / Jonas
Received on Monday, 10 September 2012 12:34:18 UTC