[Bug 22459] [Custom]: Consider explicitly emptying callback queue in more cases

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

--- Comment #15 from Dominic Cooney <dominicc@chromium.org> ---
I took a shot at implementing this in Blink; next we'll see what some web
developers think.

Here is some implementor feedback:

The processing stack is a curious structure; callback queues enter the
processing stack but then migrate within it. But they only migrate upwards
because the callback queues are processed exhaustively (although that
processing might be interrupted if the callback queue migrates up, then
resumed.)

I'm not 100% sure how this interacts with microtasks now. Since the
DOM-modifying methods push and pop from the processing stack, I think this
means there's nothing to do at microtask checkpoints any more. Does that sound
right?

One last minor question: When it is time to schedule a callback, should the
callback queue migrate to the top of the processing stack even if that element
did not register that callback? For example in this case:

Assume x-a, x-b and x-c:
- x-a has an enteredDocument callback that grabs x-c and sets an attribute
- x-b & x-c have an enteredDocument callback that logs
- x-c *has* an attributeChangedCallback.

Given:

document.body.innerHTML = '<x-a></x-a><x-b></x-b><x-c></x-c>'

I think processing stack should produce this ordering:

enter innerHTML
  x-a enteredDocument, callback enters setAttribute
    x-c enteredDocument  <-- x-c has been pulled to processing stack T.O.S.
    x-c attributeChanged
  leave setAttribute
  x-b enteredDocument
leave innerHTML

Now imagine x-c doesn't have an attributeChanged callback. Is the order the
same (minus x-c attributeChanged?) Or is it

enter innerHTML
  x-a enteredDocument, callback calls setAttribute but no recursion
  x-b enteredDocument
  x-c enteredDocument
leave innerHTML

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 9 July 2013 01:35:13 UTC