[whatwg/dom] MutationObserver invocation order (#713)

Based on: https://github.com/jsdom/jsdom/pull/2398#discussion_r230243035

While implementing MutationObserver in jsdom, I wasn't able to make the following test pass: https://github.com/web-platform-tests/wpt/blob/master/shadow-dom/slotchange-event.html#L540-L594

The test run the following steps:
1. Adds 2 mutation observers (one on `id` attribute and another one on `title`) and a slot with a `slotchange` event handler.
2. Update the `id` attribute and the append a child in the light dom of the host. We then enqueue a microtask to notify the listeners. At this point the `id` attribute mutation observer contains 1 mutation record, and the signal slot list contains the slot.
3. The [notifiy mutation observer](https://dom.spec.whatwg.org/#notify-mutation-observers) algorithm is executed later on:
 1. The mutation observer list is copied, it contains the 2 mutation observers, and it iterates over the 2 mutation observers
 2. The callback for the `id` mutation observer is executed and in it's callback it updates title attribute and append a new element the light dom of the host. By updating the `title` attribute a new mutation record is enqueued but this time for the `title` mutation observer.
 3. The callback for the `title` mutation observer is invoked because it has a mutation record. And the test throws here since it expects that the `slotchange` event is invoked first.

[Chrome](https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/mutation_observer.cc?sq=package:chromium&g=0&l=349-350) and [Webkit](https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/MutationObserver.cpp#L273) don't run into the same issue since they keep track of an active mutation observer list instead of iterating over all the mutation observers.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/713

Received on Friday, 2 November 2018 01:52:51 UTC