- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Sun, 11 Mar 2012 23:45:26 +0200
- To: Adam Klein <adamk@chromium.org>
- CC: www-dom@w3.org, Anne van Kesteren <annevk@opera.com>, Olli@pettay.fi
On 03/07/2012 06:52 PM, Adam Klein wrote: > http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-mo-invoke > describes 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 about: > > 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 queue. > > 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). > > Thoughts? Sounds ok. > Also, if the above is too hard to follow, I have test-cases > that demonstrate these cases, and could point at those instead. > > - Adam
Received on Sunday, 11 March 2012 21:46:26 UTC