In particular, I don't see how propagating it across Web IDL callbacks works. Think things like:
setTimeout(someWindow.postMessage.bind(someWindow, stuff), 0);
and what the incumbent settings object will be when postMessage is invoked. What will it be with the spec as it's written right now.

It looks like the bug here is that bound functions are not created with a ScriptOrModule. They should be created with the current execution context's ScriptOrModule. I can PR ES to fix that. If that gets fixed then step 2 of GetActiveScriptOrModule() will return the bound function's execution context.

Did you have something else in mind though?

I assume the entry settings object in this case will be something sane-ish, in that it will be associated with the Function that is the return value of bind in this case, right?

This is unclear to me because IDL's "invoke" (which is what setTimeout references) is has not been up to date with HTML for a long time (way before my changes). It's unclear whether it uses "prepare to run a callback" and "clean up after running a callback". I guess if we fixed IDL it would:

Accept the bound function
Convert it to an IDL callback type whose "callback context" was the bound function's ScriptOrModule component's settings object
When it's time to invoke the IDL callback type, prepare to run a callback using the "callback context" (and clean up with the same callback context afterward).

In that case yes the entry settings object would be the settings object of the bound function. Which I believe would be the same as the incumbent per my above reasoning.

Oh, and importantly are there ever JavaScript execution contexts that do not have a script or a module associated with them? If not, why not? What is the ScriptOrModule when the callback function is called in the case above?

The intent was that only the very top-level contexts, which are basically a spec artifact, should be missing ScriptOrModule. You found a bug for bound functions, but otherwise it should be the case always.

Digging into the ES end of this a bit more, builtin functions have [[ScriptOrModule]] set to null, afaict. See https://tc39.github.io/ecma262/#sec-createbuiltinfunction

Right. The idea is that when digging up the stack for the closest ScriptOrModule you have to skip over built-in functions.

As far as entry settings objects... I'm not sure what "the script corresponding to the running execution context" is in the EnqueueJob section in the HTML spec. Why would there be such a script at all? See builtin functions above.

That was supposed to link to https://html.spec.whatwg.org/#script-corresponding-to-the-running-execution-context. I have no idea why it does not :(. As explained above though there should always be such a script.

Also, a related issue is that https://html.spec.whatwg.org/multipage/webappapis.html#runtime-script-errors-in-documents assumes there is a script, which is not the case for a builtin function, bound or not, being called directly as a callback.

I think this has always been that way :-/.

"Rewrite script execution on top of ES" fallout #473

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions