Missing calls to GetActiveScriptOrModule in PerformEval and EnqueueJob?

[anba]

For indirect eval and EnqueueJob calls, ScriptOrModule of the new execution context resp. new job is set to null (*), but maybe it should instead use the active script/module? Functions created through CreateDynamicFunction use the active script/module. And the dynamic import proposal also expects ScriptOrModule is set to a non-null value in https://tc39.github.io/proposal-dynamic-import/#sec-import-call-runtime-semantics-evaluation.

(*) It's null because the running execution context is the exec-context of a built-in function, and ScriptOrModule of exec-contexts of built-in functions is always null (https://tc39.github.io/ecma262/#sec-createbuiltinfunction).

[bterlson]

cc @domenic

[anba]

The example I had in my mind for the dynamic import proposal are:

// File: example.js
Promise.resolve(`import("./example.js").catch(e => print("caught", e))`)
       .then(eval);

and

// File: example.js
Promise.resolve(`import("./example.js").catch(e => print("caught", e))`)
       .then(Function)
       .then(Function.prototype.call.bind(Function.prototype.call));

[domenic]

So to be clear, in those examples, it seems like GetActiveScriptOrModule() will not find anything on the stack where the ScriptOrModule component is not null, right? Yeah, I guess that is bad.

One fix might be that EnqueueJob() should be using GetActiveScriptOrModule() instead of getting the running execution context's Realm's ScriptOrModule. What do you think of that?

Do you think eval needs to be fixed separately, or does the above take care of both of your examples?

[anba]

So to be clear, in those examples, it seems like GetActiveScriptOrModule() will not find anything on the stack where the ScriptOrModule component is not null, right?

Correct.

One fix might be that EnqueueJob() should be using GetActiveScriptOrModule() instead of getting the running execution context's Realm's ScriptOrModule. What do you think of that?

I can't really tell, because I don't know where and when GetActiveScriptOrModule() is used (except for its use in the dynamic import proposal). Sorry!

Do you think eval needs to be fixed separately, or does the above take care of both of your examples?

It should be sufficient to change EnqueueJob, because there should always be another execution context on the stack with a non-null ScriptOrModule component when eval is executed.

[domenic]

I looked into this but it seems this is just part of the general brokenness of EnqueueJob. In reality nobody implements it as specced; they let the host environment take care of the job queuing. So this is addressed by #735... which would indeed be great to get merged.

[anba]

#735 doesn't initialize any of the new execution context's components, so I don't see how that PR helps the dynamic import proposal to assert that there's always a non-null ScriptOrModule component during the evaluation of import().

[domenic]

It should be sufficient to change EnqueueJob, because there should always be another execution context on the stack with a non-null ScriptOrModule component when eval is executed.

I believe this doesn't hold in the following case:

button.setAttribute("onclick", `
  Promise.resolve('import("./example.js").catch(e => print("caught", e))')
       .then(eval);
`);

If the user actually clicks on the button (instead of script calling .onclick() or .click()), then we eventually end Call()ing a function created in step 10 of get the current value of the event handler. But that function is created with only the Realm execution context on the stack, which has no ScriptOrModule.

I'll probably continue discussing this in whatwg/html#3295...