W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

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

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Wed, 12 Sep 2012 10:17:39 +0200
Message-ID: <50504523.3030406@helsinki.fi>
To: WebApps WG <public-webapps@w3.org>
CC: Jonas Sicking <jonas@sicking.cc>, Adam Klein <adamk@chromium.org>, Ian Hickson <ian@hixie.ch>, Mihai Parparita <mihaip@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>, Anne van Kesteren <annevk@annevk.nl>, Rafael Weinstein <rafaelw@chromium.org>
On 09/12/2012 08:21 AM, Olli Pettay wrote:
> On 09/10/2012 02:33 PM, Jonas Sicking wrote:
>> 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
> It is not clear to me we need to change the spec
> (except that it should say mutation records are created during parsing).
> If someone wants to get mutation records earlier than
> end-outermost-microtask-or-end-of-innermost-task, there
> is always takeRecords().
> -Olli

Though, if we want app/dom state to be stable before executing <script>, we could
make parser insertions to be microtasks. Then right after inserting a <script> to a document,
but before executing the script mutation callbacks would be called.

Received on Wednesday, 12 September 2012 08:18:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:38 UTC