[Bug 22759] It is not clear what happens to the existing transient observers when MutationObserver.observe is called

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22759

Travis Leithead [MSFT] <travil@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #9 from Travis Leithead [MSFT] <travil@microsoft.com> ---
The fix does not quite match what implementations are doing. Here's what I
think is further required:

In the "To remove a node from a parent, optionally with suppress observers flag
set, run these steps:" algorithm, step 7 says to create a transient registered
observer and append it to node's list of registered observer. We need to
additionally be able to track this transient registered observer's relationship
to the original node so that when observe() is called again with the original
target and options, this "forked" registered observer can also be removed
(which it is not according to the current algorithm that only iterates the
target's list of registered observers.

This can be accomplished a number of ways, for example, adding a list of child
transient observers for each registered observer (and traversing it at the
appropriate time). However, the simplest way to do this re-using existing lists
and with minimal changes to the spec seems to be the following:

1. In step 7 of the above-mentioned algorithm, the node newly associated with
the transient registered observer needs to be additionally added to the context
object's list of nodes.

2. Step 2 of "The observe(target, options) method must run these steps:"
algorithm, must be expanded. Instead of iterating target's list of registered
observers, it must actually iterate the context object's list of nodes, and
then for each node iterate that node's list of registered observers looking for
transient registered observers whose "observer" matches the context object and
removing it. Then it has to explicitly perform current step 2.2 on just the
target's list of registered observers (or you would end up resetting other
nodes you legitimately independently registered on).

Bonus:
Additionally, step 2.3 of the "To invoke MutationObserver objects, run these
steps:" algorithm can be made more explicit--in that it traverse's mo's list of
nodes, and for each node in said list, it searches the node's list of
registered observers for those that refer to mo and removes them all.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 29 July 2013 18:34:08 UTC