-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Normative: Do not capture the script/module in new Function and indirect eval
#3374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Normative: Do not capture the script/module in new Function and indirect eval
#3374
Conversation
| </td> | ||
| <td> | ||
| a Script Record or a Module Record | ||
| a Script Record, a Module Record, *null* or ~hidden~. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think this can be null (or appear to be null in the case of ~hidden~?). See for example #1670.
and so this leads me to my question, why not just create a new script record for indirect evaluators?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be null when you define a function inside an inline event handler in HTML, since in that case GetActiveScriptOrModule() is null.
and so this leads me to my question, why not just create a new script record for indirect evaluators?
That would work too, but we probably need a new host hook to let hosts define the [[HostDefined]] slot of those new script records created within ECMA-262.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess another perspective is that the ecmascript code being evaluated is not technically from a Script or a Module. Though it would seem to clean up the existence of HideParentScriptOrModule if we set something there explicitly.
| 1. If _F_.[[ScriptOrModule]] is ~hidden~, then | ||
| 1. Set the ScriptOrModule of _calleeContext_ to *null*. | ||
| 1. Set the HideParentScriptOrModule of _calleeContext_ to *true*. | ||
| 1. Else, | ||
| 1. Set the ScriptOrModule of _calleeContext_ to _F_.[[ScriptOrModule]]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be unchanged and propagate ~hidden~ up to GetActiveScriptOrModule, which could turn it into null?
| HideParentScriptOrModule | ||
| </td> | ||
| <td> | ||
| A Boolean indicating wether, when looking for an execution context with a non-*null* ScriptOrModule component, this execution context should allow looking at its ancestors or not. If not explicitly set, defaults to *false*. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| A Boolean indicating wether, when looking for an execution context with a non-*null* ScriptOrModule component, this execution context should allow looking at its ancestors or not. If not explicitly set, defaults to *false*. | |
| A Boolean indicating whether, when looking for an execution context with a non-*null* ScriptOrModule component, this execution context should allow looking at its ancestors or not. If not explicitly set, defaults to *false*. |
We have three ways of dynamically executing code:
evalevalnew Function&friendsThe main difference is that direct
evalhas some magic behavior, capturing the context where it's being called, while indirectevalandnew Functionare supposed to be "normal functions" that do not perform any dynamic scoping.There is however a case where indirect
evalandnew Functionare affected by where they are being called: they propagate the active script or module.This pull request changes them to instead run their code with a null ScriptOrModule, similarly to code run in HTML event handlers. This ensures that the behavior of indirect
evalandnew Functiondoes not depend on where they are called. The observable change is that in(eval, 0)("import('./foo')"),./foois resolved relative to the base URL of the Realm and not of the script or module callingeval(and same fornew Function).I believe that this PR can be web compatible because there is currently different behaviors across different browsers (see #3160 for more details).
Fixes #3160.