[Bug 20131] New: [MutationObservers] Unclear whether unique record instances are required in 5.3.2 "Queuing a mutation record"

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

            Bug ID: 20131
           Summary: [MutationObservers] Unclear whether unique record
                    instances are required in 5.3.2 "Queuing a mutation
                    record"
    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

Given the updated algorithm in 5.3.2 (Queuing a mutation record), if I have
four unique observers, each observing a single DOM Text node, and I cause a
mutation to that text node, then should I expect to see four unique record
objects (one in each of the observer's queues), or one unique record object
that is referenced from each of the four queues?

I suspect that the intent of the spec is that four unique records are created
and each unique record object resides in each queue, thus:
var recList1 = ob1.takeRecords();
var recList2 = ob2.takeRecords();
var recList3 = ob3.takeRecords();
var recList4 = ob4.takeRecords();

assert((recList1[0] !== recList2[0]) &&
       (recList2[0] !== recList3[0]) &&
       (recList3[0] !== recList4[0]) &&
       (recList4[0] !== recList1[0]) &&
       (recList1[0] !== recList3[0]) &&
       (recList2[0] !== recList4[0]));

This is the behavior I see in Firefox.

The spec is ambiguous in step 7.2 where it says to append the record to the
observer's record queue. A literal reading of this (to me) indicates that there
is only one single record object and it will belong to each of the record
queues it is appended to--but this is contrary to the behavior seen in Firefox.
To align with Firefox, step 7 might have a step 0 which reads, let rec be a
copy of record.

If, in fact the spec is meant to only have a single instance of the record
object reside in each of the queues, then there's still an ambiguity with
regard to how oldValue is populated. The spec's algorithm would populate
oldValue on the record and all observers would get the old value on the record
if any one of them wanted it--is that the desired behavior? No browser
currently implements it that way. Chrome comes close. Given the four observers
case above, if two of them (2 & 4) request the old value, then Chrome creates 2
unique instances of the record and gives observers 1 & 3 one instance (without
the oldValue) and 2 & 4 the other instance so that:
assert(recList1[0] === recList3[0])
assert(recList2[0] === recList4[0])

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 28 November 2012 19:49:27 UTC