Are the “active script” & “base URL” assertions in the timer initialization steps correct?

[bathos]

The assertion at step 8 of the timer initialization steps —

7. Let initiating script be the active script.
8. Assert: initiating script is not null, since this algorithm is always called from some script.

— seems like it may be incorrect? If I’m reading this right, active script and GetActiveScriptOrModule would return null for the second invocation of “timer initialization steps” kicked off by setTimeout(setTimeout.bind(this, () => {})), for example.

The initiating script is used by the task created at step 9 to determine the base URL if the handler is a string, with another assertion (under 9.3):

4. Let base URL be initiating script's base URL.
5. Assert: base URL is not null, as initiating script is a classic script or a JavaScript module script.

If I’m correct that these assertions are wrong, I suspect base URL should be getting set to the API base URL of the settings object of the incumbent realm (captured prior to the step 9 task steps) when initializing script is null. Or something like that.

[domenic]

I think you're right. The execution context stack just consists of the realm execution context, and nothing else.

This was added in 12cdfef. It seems the issue was discussed in #3117 and #3163 was supposed to fix it, but only fixed it for something like Promise.resolve().then(setTimeout.bind(...)) and not for setTimeout(setTimeout.bind(...))?

So yeah, we should probably account for cases like this, similar to the defaulting we do in https://html.spec.whatwg.org/#hostloadimportedmodule .

[domenic]

I see. This is basically a symptom of whatwg/webidl#902. If we properly propagated the active script, this would not be an issue. But we don't, and I've kind of given up on anyone implementing that.