Also note that microtask processing runs in a loop until they are all gone:

"3. If any MutationObserver object in scripting environment's list of MutationObserver objects has a non-empty record queue at this point, run these steps again (indeed, all of them)."

<http://dom.spec.whatwg.org/#mutation-observers>

Lifecycle events should do the same, I think.

Disregard Comment 1, I see that the looping aspect is there, just the language differs.

(In reply to comment #0)
> Consider the case where a MutationObserver callback does something that
> causes a lifecycle callback to be enqueued. That lifecycle callback may
> never be delivered.

Well, MutationObserver callback itself forms a microtask.

(In reply to comment #3)
> (In reply to comment #0)
> Well, MutationObserver callback itself forms a microtask.

I'm going off "microtask checkpoint" as described here: <http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#perform-a-microtask-checkpoint>

I must be missing something obvious here. From my reading of the spec, implementations would:

1. Run lifecycle callbacks until they're exhausted.
2. Run MutationObservers until they're exhausted.
(Microtask checkpoint done.)

What happens to lifecycle callbacks that are scheduled during step 2? Before the next checkpoint the document may go away, etc.

It seems this should instead be:

While there are lifecycle callbacks or mutation observations:
  While there are lifecycle callbacks
    Deliver lifecycle callbacks
  While there are mutation observations
    Deliver mutation observations

So it seems to me that Lifecyle events are similar enough to mutation observers that makes sense considering abstracting the mutation observer delivery mechanism to essentially allow Lifecycle event callbacks to act as observers.

Imagine that HTML defines an abstract EOMT processing model like:

-EOMTWorker

static Vector<EOMTWorker> activeWorkers

static activateWorker(EOMTWorker worker) {
  if (!activeWorkers.contains(worker))
    activeWorkers.append(worker);
}

static isDelivering = false;

static processEOMTCheckpoint() {
  if (isDelivering)
    return;
  isDelivering = true;

  while (!activeWorkers.empty()) {
    deliverNow = activeWorkers.copy();
    activeWorkers.clear();
    forEach worker in deliverNow {
      worker.invoke(); // may run script, which may activate other workers
                       // may also decide to do nothing if it no longer needs to
    }
  }

  isDelivering = false;
}

(In reply to comment #5)
> So it seems to me that Lifecyle events are similar enough to mutation
> observers that makes sense considering abstracting the mutation observer
> delivery mechanism to essentially allow Lifecycle event callbacks to act as
> observers.
> 
> Imagine that HTML defines an abstract EOMT processing model like:
> 
> -EOMTWorker
> 
> static Vector<EOMTWorker> activeWorkers
> 
> static activateWorker(EOMTWorker worker) {
>   if (!activeWorkers.contains(worker))
>     activeWorkers.append(worker);
> }
> 
> static isDelivering = false;
> 
> static processEOMTCheckpoint() {
>   if (isDelivering)
>     return;
>   isDelivering = true;
> 
>   while (!activeWorkers.empty()) {
>     deliverNow = activeWorkers.copy();
>     activeWorkers.clear();
>     forEach worker in deliverNow {
>       worker.invoke(); // may run script, which may activate other workers
>                        // may also decide to do nothing if it no longer
> needs to
>     }
>   }
> 
>   isDelivering = false;
> }

I agree. The spec already has sorting tables as a separate sequential step in microtask checkpoint, which means we could definitely end up  with pending sorts when exiting the the checkpoint:

http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#perform-a-microtask-checkpoint

Should attempt to monkey-patch this in custom elements spec? That seems a bit crazy :)

https://dvcs.w3.org/hg/webcomponents/rev/4963a4286660

There, FTFY.