Re: DOM Mutation Events Replacement: When to deliver mutations

On Thu, Aug 11, 2011 at 9:12 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
> On 08/11/2011 06:13 PM, Rafael Weinstein wrote:
>>>
>>> Con:
>>> Since the approach is bound to tasks, it is not clear what should happen
>>> if event loop spins while handling the task. What if some other task
>>> modifies the DOM[1], when should the mutation callbacks fire?
>>> Because of this issue, tasks, which may spin event loop, should not
>>> also modify DOM since that may cause some unexpected result.
>>
>> I think the *pro* side of this you listed is more fair. Both Options 2
>> &  3 must answer this question. It's true that because Option 3 is
>> later, it sort of has this issue "more".
>
> And it has a lot "more". Since for example when handling an event, all
> the listeners for it are called in the same task and if one event
> listener modifies DOM and some other spins event loop, it is hard to
> see what is causing the somewhat unexpected behavior.
>
>
>>
>> However, "what should happen" has been defined. In both cases, if
>> there are any mutations which are queued for delivery when an inner
>> event loop spins up, they are *not* delivered inside the inner event
>> loop. In both Options, they are always delivered in the loop which
>> queued them.
>
> But what happens when event loop spins within a task, and some
> "inner" task causes new mutations?
> We want to notify about mutations in the order they have happened, right?

In general, yes. But I believe the idea is that spinning an inner
event loop is an exception. In that case delivering mutations in the
order they were generated will be broken. To be perfectly precise:
Mutations will be delivered in the order they were generated *for and
within any given event loop*.

There's no question this is unfortunate. The case in which the bad
thing happens is you:

-Made some modifications to the main document
-Used showModalDialog
-Modified the opener document from the event loop of showModalDialog
-Got confused because mutations from within the showModalDialog were
delivered before the mutations made before calling it

I suppose this comes down to judgement. Mine is that it's acceptable
for us to not attempt to improve the outcome in this case.

> So if there are pending mutations to notify, the inner task must just
> queue notifications to the queue of the outermost task.
> This could effectively disable all the mutation callbacks for example when a
> modal dialog (showModalDialog) is open.
>
>
> Option 2 has similar problem, but *only* while handling mutation callbacks,
> not during the whole task.
>
>
>
> -Olli
>
>
>
>>
>>>
>>> Callback handling is moved far away from the actual mutation.
>>>
>>>
>>> Pro:
>>> Can batch more, since the callbacks are called later than in
>>> option 2.
>>>
>>>
>>> -Olli
>>>
>>>
>>> [1] showModalDialog("javascript:opener.document.body.textContent = '';",
>>> "",
>>> "");
>>>
>>
>>
>
>

Received on Thursday, 11 August 2011 16:35:59 UTC