Re: [UndoManager] Re-introduce DOMTransaction interface?

On Wed, Jul 4, 2012 at 10:00 PM, Adam Barth <w3c@adambarth.com> wrote:
> On Wed, Jul 4, 2012 at 5:25 PM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
>> On 07/05/2012 03:11 AM, Ryosuke Niwa wrote:
>>>
>>> On Wed, Jul 4, 2012 at 5:00 PM, Olli Pettay <Olli.Pettay@helsinki.fi
>>> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>>>
>>>     On 07/05/2012 01:38 AM, Ryosuke Niwa wrote:
>>>
>>>         Hi all,
>>>
>>>         Sukolsak has been implementing the Undo Manager API in WebKit but
>>> the fact undoManager.transact() takes a pure JS object with callback
>>>         functions is
>>>         making it very challenging.  The problem is that this object needs
>>> to be kept alive by either JS reference or DOM but doesn't have a backing
>>> C++
>>>         object.  Also, as far as we've looked, there are no other
>>> specification that uses the same mechanism.
>>>
>>>
>>>     I don't understand what is difficult.
>>>     How is that any different to
>>>     target.addEventListener("foo", { handleEvent: function() {}})
>>>
>>>
>>> It will be very similar to that except this object is going to have 3
>>> callbacks instead of one.
>>>
>>> The problem is that the event listener is a very special object in WebKit
>>> for which we have a lot of custom binding code. We don't want to implement a
>>> similar behavior for the DOM transaction because it's very error prone.
>>
>>
>> So, it is very much implementation detail.
>> (And I still don't understand how a callback can be so hard in this case.
>> There are plenty of different kinds of callback objects.
>>  new MutationObserver(some_callback_function_object) )
>
> I haven't tested, by my reading of the MutationObserver implementation
> in WebKit is that it leaks.  Specifically:
>
> MutationObserver --retains--> MutationCallback --retains-->
> some_callback_function_object --retains--> MutationObserver
>
> I don't see any code that breaks this cycle.
>
> DOM events have a bunch of delicate code to avoid break these
> reference cycles and avoid leaks.  We can re-invent that wheel here,
> but it's going to be buggy and leaky.
>
> I appreciatie that these jQuery-style APIs are fashionable at the
> moment, but API fashions come and go.  If we use this approach, we'll
> need to maintain this buggy, leaky code forever.  Instead, we can save
> ourselves a lot of pain by just using events, like the rest of the web
> platform.

Again, this sounds like a webkit specific shortcoming. It's inevitable
that there will be cycles between "platform objects" and JS objects.
The way to collect these cycles is to use the same logic as in normal
JS objects. I.e. detect when a group of objects have no incoming
references and then collect them. I.e. use mark-and-sweep or similar
logic.

I think it would be a severe limitation in the types of APIs that we
can create if we say that cycles between platform objects and JS
objects can only be allowed if the cycle is through event handlers. It
also seems like a very arbitrary limitation. It would effectively mean
that we can't have any interface which uses callbacks other than using
event handlers, unless those callbacks are known to always fire and
always fire exactly once.

I certainly agree that fixing this is no easy matter. It's something
that we have worked on a lot in Gecko and continue to work on. But I
don't see how we can build a platform based on a garbage collected
language like javascript without it.

/ Jonas

Received on Friday, 6 July 2012 23:02:52 UTC