https://wicg.github.io/scheduling-apis/#sec-scheduler-alg-scheduling-tasks doesn't explain what happens if the associated document isn't fully active

[smaug----]

What should happen if one uses scheduler from an iframe which has been removed from its parent document?

[shaseley]

Good question. The intent was that tasks posted to a detached iframe's scheduler would not run (like tasks in the event loop's task queues), and this should get handled by downstream fully-active checks: if a detached iframe's scheduler has any queued tasks, they won't be selected to run because the tasks won't be runnable (the fully active check from event loops's runnable would fail).

Given that, the behavior (as written) of posting a task to a detached scheduler would be:

1. Queue a task that would never run. For delayed tasks, we would technically not queue the task because the wait for timeout step would hang due to the fully-active check.

2. Return a promise that would never be settled

In our implementation we actually throw an exception if you try to post a task to detached iframe's scheduler, causing the call to postTask to return a rejected promise (which obv doesn't match this). I think either behavior is probably okay, but would lean towards the unresolved promise (possibly with an explicit check if it helps clarify) to match behavior of already posted tasks. That would also match setTimeout, which doesn't throw an error in this case (and IIUC relies on downstream fully active checks in run steps after timeout).

[domenic]

Note that in theory the task could run/the promise could be settled once the document comes out of bfcache... in practice, since browsers don't bfcache iframes or windows with openers, this is not observable.