Fwd: MutationObserver - a better interface

forgot to send to list

---------- Forwarded message ----------
From: Bradley Meck <bradley.meck@gmail.com>
Date: Tue, Feb 11, 2014 at 8:21 PM
Subject: Re: MutationObserver - a better interface
To: Axel Dahmen <brille1@hotmail.com>


They are used while they observe least 1 Node (sometimes you observe more
than 1); I still have uses where I have multiple views and need to keep
them in sync (darn contenteditable). Having multiple Nodes observed at once
is a use case why you don't want this on Node (but you can always abstract
this away, but then you are talking about multiple aggregations for the
MutationRecords... which is sad times).

Also, if the MutationObserver is exposed as a means to provide behavior
based upon a closure you are talking about passing around multiple
references to a function which a user script could easily invoke for
nefarious means. For example if we have a contenteditable that we use to
see if someone has somehow poisoned our offline app's security:

m=new MutationObserver(function (records) {
  // testAppStateNotHijacked should be in a closure
  if (records.some(recordCanHijackApp)) {
    logout();
  }
   else {
    saveHTMLState();
  }
});

As an internal field to MutationObserver, the function is still safe (not
talking about debuggers) to the user. If we are passing that function
around to each Node, can we make that guarantee that someone won't send in
an object that uses a fake records.some?


On Tue, Feb 11, 2014 at 7:58 PM, Axel Dahmen <brille1@hotmail.com> wrote:

> Sure, but that's no contradiction to the fact that a MutationObserver is
> always attached to a Node object.
>
> Even if the code you mentioned removes the node from the object tree and
> re-adds it again, it still stays the same Node object. So if the
> MutationObserver interface would have been added to a Node object, all
> references would still be valid and in place.
>
> And please consider the case when a node simply gets removed:
>
>    var myNode = document.getElementById("myNode");
>    myNode.parentNode.removeChild(myNode);
>
> If the MutationObserver interface would have been implemented at the Node
> class, there was a natural correlation between the node and events being
> tracked for children of that node.
>
> My assumption is that every current DOM application implementation
> distinguishes between hard and soft references. When a node is neither
> attached to any document nor referenced by any JavaScript variable it won't
> fire any more mutation events, without doubt.
>
> It doesn't make sense to provide a reference to a separate
> MutationObserver object, being isolated from the Node object it observes.
> It most easily may become orphaned and invalid.
>
> Regards,
> Axel Dahmen
> www.axeldahmen.de
>
>
>
> ----------
> "Anne van Kesteren"  schrieb im Newsbeitrag news:CADnb78jBbR+
> Wd5f3ZamnASXVmSQTaYat4bSAzROuktRpQs9OUg@mail.gmail.com...
>
>
> On Tue, Feb 11, 2014 at 6:34 PM, Axel Dahmen <brille1@hotmail.com> wrote:
>
>> But, well, that's, too, even one more point for having had
>> MutationObserver
>> being a Node's member as it doesn't make any sense to observe a Node you
>> don't have any more references to in code.
>>
>
> As I said you often do keep a reference to the node.
>
> E.g. document.head.appendChild(document.body) will first remove
> document.body and then insert it again. It would be bad if the
> observer was destroyed while this operation took place as subsequent
> document.body.appendChild(...) invocations would go unrecorded.
>
>
> --
> http://annevankesteren.nl/
>
>
>
>