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

[Bug 21338] New: Gut check on when to clear transient registered mutation observers

From: <bugzilla@jessica.w3.org>
Date: Tue, 19 Mar 2013 16:07:41 +0000
To: www-dom@w3.org
Message-ID: <bug-21338-4009@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21338

            Bug ID: 21338
           Summary: Gut check on when to clear transient registered
                    mutation observers
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM
          Assignee: annevk@annevk.nl
          Reporter: travil@microsoft.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

Background (my understanding of transient registered mutation
observers--TRMOs):
------------------------
I believe that TRMOs are designed the way they are to make it so that the order
of removal mutations becomes largely unimportant to ensuring an observer
receives a complete view of all the changes between individual checkpoints. 
Given the following tree:

<div>
    <p>
        <span>
        </span>
    </p>
</div>

If you attach an observer to the <div>, remove the <span>, and then remove the
<p>, you’ll see two mutation records generated.  If you reverse the order of
the removals, however, you would only see the removal record for the <p>, if
not for TRMOs.  With TRMOs, when the <p> is removed, a TRMO is attached to it,
and then the removal of the <span> can be observed, which would otherwise be
lost due to the <div> not being in the <p>’s parent chain anymore.

Spec assessment:
------------------------
The spec states that TRMOs are to be removed at checkpoint time.  They’re not
supposed to be permanent, they’re just supposed to be there long enough for
script to see that some the <p> left the tree.  If it’s interested, it can
register an observer on it and not miss anything as things move forward.

Question to consider:
------------------------
Do we think checkpoint time is the right time to remove TRMOs? The spec and
Firefox/Chrome do it that way. However, after thinking about this for a while,
I think the right time is actually any time the list of records is retrieved
(checkpoint time, as well as calls to takeRecords). If TRMOs are not removed
during takeRecords, then script will continue to receive transient observer
notifications anytime between that call to takeRecords and the future
checkpoint, and this to me seems confusing and possibly unwanted.  When
takeRecords is called, the array contains the removal record for the <p>, but
script will continue to receive transient records until the next checkpoint. 
Perhaps weirder, if script does attach an observer to the <p> right after
calling takeRecords, then it’ll potentially get double removal records until
the next checkpoint (and there isn’t an easy way to avoid this, short of it
manually deduplicating the records).

Thoughts? Should the spec be changed so that TRMOs are additionally cleared at
takeRecords() time?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 19 March 2013 16:07:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 19 March 2013 16:07:50 GMT