-
Notifications
You must be signed in to change notification settings - Fork 42
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
Support sandboxed script execution #158
Conversation
This allows us to get a realm id back when we execute in a sandbox.
Sandboxes are always associated with a context, so change the target type to allow specifying a sandbox name, and when the name is specifed, get or create a sandbox with that name to execute the script in.
Started discussion offline:
Potential solution for that would be excluding DOM instances from the serialization and consider serialization only from the ECMAScript realm perspective. Having that, another way to describe the node is needed. Another solution is to add something like Implementation-wise in CDP we face the need of somehow merging domains (Runtime (V8) runs Having that, we'd consider split DOM instances from it's JS wrappers, leaving the last in default serialization. And introducing DOM-specific serialization like |
I created #176 for the discussion in that comment. |
<div algorithm> | ||
To <dfn>get or create a sandbox realm</dfn> given |name| and |source browsing context|: | ||
|
||
1. If [=context sandbox map=] does not contain |name|, set |source browsing |
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.
Looks like this algorithm doesn't quite align with the type of context sandbox map
described above. Should this step check if context sandbox map
contains source browsing context
instead of name
since it is a weak map whose keys are browsing contexts?
<dd> | ||
|
||
<dt>The [=module map=] | ||
<dd>Issue: Not sure if this ought to be the module map of the assocaited |
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 suspect this should be an empty module map. If I'm understanding correctly, using the document's module map would mean that any names exported by module scripts on the page are now accessible in the sandbox if it imports the modules. This would break the isolation between the two realms.
@jgraham this is in draft still, do you want review, or what's needed to unblock it? |
|
||
1. If |P| is a [=member=] of an [=interface=] implemented by |wrapped|: | ||
|
||
1. If |P| is an [=atrthtmlibute=], let |getter| be the [=attribute getter=] |
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.
Is "atrthtmlibute" a typo?
Yeah, let's just close this for now; we can always ressurect the changes if we want to use any of the more detailed text about how sandboxes work in terms of the platform. |
Allow running scripts in a sandbox environment, such that they have access to the DOM of page, but don't share js-level state with the page.
Preview | Diff