What if we try to run setTimeout on not fully active document

Question

I have wondering a question, how do timers work? Sure after that I towarded to read whatwg spec and I came across on the following text:

If global is a Window object, wait until global's associated Document has been fully active for a further milliseconds milliseconds (not necessarily consecutively).

Well, how can I reproduce this case? And how I can track when document will be fully active?

---

By the way I've made interesting example by that case:

let iframe = document.createElement("iframe");
document.body.append(iframe);
void setTimeout(() => {
  let windowIframe = frames[0];
  windowIframe.frameElement.remove();
  let id = windowIframe.setTimeout(() => console.log("hello"));
  console.log(id);
})

If you run it at your local machine, you will see 0 in the console and the code with "hello" will never printed. What do you think where this behaviour came from specification?

Answer 1

And how I can track when document will be fully active?

There's already an answer here regarding what is means for a document to be fully active: Detecting when a document is "fully active"

Well, how can I reproduce this case?

There is some extensive discussion here: https://github.com/whatwg/html/issues/8002

If you run it at your local machine, you will see 0 in the console

For entries put in the map of active timers by the timer initialization steps, i.e., by setTimeout() and setInterval(), the keys are numbers.

Furthermore:

A browsing context is an environment in which Document objects are presented to the user. A tab or window in a web browser typically contains a browsing context, as does an iframe or frames in a frameset.

A Document's browsing context is the browsing context whose session history contains the Document, if any such browsing context exists and has not been discarded, and null otherwise.

A Document does not necessarily have a non-null browsing context. In particular, data mining tools are likely to never instantiate browsing contexts. A Document created using an API such as createDocument() never has a non-null browsing context. And the Document originally created for an iframe element, which has since been removed from the document, has no associated browsing context, since that browsing context was discarded.

A Document d is said to be fully active when d's browsing context is non-null, d's browsing context's active document is d, and either d's browsing context is a top-level browsing context, or d's browsing context's container document is fully active.

Answer 2

So let me see if I get what you're asking... First off, the reason that setTimeout()'s callback isn't executing is that before even calling setTimeout(), you remove the iframe containing windowIframe. To see the output of console.log("hello"), you would need to delete the iframe after calling console.log(), so something like this:

let iframe = document.createElement("iframe");
document.body.append(iframe);
void setTimeout(() => {
    let windowIframe = frames[0];
    let id = windowIframe.setTimeout(() => {
        console.log("hello");
        windowIframe.frameElement.remove();
    });
    console.log(id);
})

// OUTPUT:
// 1
// hello

...but I guess already knew that. As to why you can use setTimeout() on an element whose window context is gone, that's an interesting question, and I'm not sure why it should be possible, since setTimeout() won't be able to execute on it. Actually, you can't in Firefox (which kind of proves my point): you will get an NS_ERROR_NOT_INITIALIZED error, so I would assume that this is actually an implementation bug by Chrome. As you alluded to before, the spec quite clearly states:

...let id be an implementation-defined integer that is greater than zero and does not already exist in global's map of active timers.

This to me sounds like the ID should never be 0, and Chrome has incorrectly implemented the spec. An error should probably be raised somewhere along the way, and the function execution should stop as it does in Firefox. But since Chrome doesn't raise an error (and even gives the incorrect ID of 0), they're probably trying to execute the function anyway, but something prevents the callback from being executed. Let's investigate:

If you inspect windowIframe in the Chrome console after removing its frameElement, you will see something like this:

>  windowIframe
<- Window {window: null, self: null, document: document, name: '', location: Location, …}

I think the relevant part of the spec is this:

9. Let task be a task that runs the following substeps:
   1. If id does not exist in global's map of active timers, then abort these steps.
   2. If handler is a Function, then invoke handler given arguments with the callback this value set to thisArg. If this throws an exception, catch it, and report the exception.

— WHATWG spec - Timer initialization steps

If I understand this correctly, your element doesn't have a global anymore since you removed the frameElement and now both windowIframe's window and self are null. Therefore, step 1 fails because "global's map of active timers" can't exist without a global and step 2, which would execute the callback function console.log("hello"), never gets gets called since the failure of step 1 aborts the execution of the subsequent steps.