W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2012

[Bug 16392] New: MutationObserver invocation order should be fixed at the beginning of each loop

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 Mar 2012 22:03:39 +0000
To: www-dom@w3.org
Message-ID: <bug-16392-4009@http.www.w3.org/Bugs/Public/>

           Summary: MutationObserver invocation order should be fixed at
                    the beginning of each loop
           Product: WebAppsWG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM
        AssignedTo: annevk@opera.com
        ReportedBy: adamk@chromium.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, Olli.Pettay@gmail.com, www-dom@w3.org

>From www-dom:

an algorithm for delivering MutationRecords to MutationObservers.
In particular, it describes an order of delivery, and I wonder if tweaking
it a little bit would make it simpler to implement. Note that I don't think
the particular order is of much importance: it's just important that there
is a well-defined order.  In particular, there are two cases I'm worried

1. Assume observers A, B, and C (created in the order A, B, C). Say that at
the beginning of the algorithm, only A and C have non-empty queues. But
during A's callback, it mutates DOM that causes a record to be added to B's

2. Assume an observer A with a non-empty queue. During its callback, it
creates a new observer B, starts B observing, and mutates DOM that adds a
record to both A's and B's queue.

By the spec, case (1) would result in the delivery order A-B-C. And (2)
would be A-B-A.

In the WebKit implementation, though, only the "active" observers (those
with records in their queues) are kept in a list (this makes it fast in the
common case that there's no delivery necessary). This makes our algorithm
more like this:

I. Make a copy of the existing "active" list, clear the list, and then
iterate over the copy.
II. When that iteration is complete, the active list is checked again; if
it's non-empty, go back to step I.

When applied to the cases above, (1) results in the order A-C-B (B doesn't
get notified until the next time around the loop), and (2) results in A-A-B
(again, the newly-added observer doesn't get notified until the second time
through the loop).

I've implemented the aforementioned algorithm in WebKit. Per the thread,
http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0145.html, it sounds
like Olli is fine with that algorithm too (CCing him just in case)

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Thursday, 15 March 2012 22:03:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:19 UTC