Proposal: dom.execute() #678
Conversation
This adds a proposal for a new dom.execute() method, which will allow synchronous execution in another "world" from a content script.
|
|
||
| **Author:** rdcronin | ||
|
|
||
| **Sponsoring Browser:** Chromee |
There was a problem hiding this comment.
| **Sponsoring Browser:** Chromee | |
| **Sponsoring Browser:** Chrome |
| There are no necessary manifest changes. | ||
|
|
||
| ## Security and Privacy | ||
|
|
There was a problem hiding this comment.
Having this API in it's current form would not make sense outside isolated worlds.
| ### Availability | |
| Initially `dom.execute()` will only be available in isolated worlds (content scripts and user scripts). | |
| This API is a necessary first step before introducing inter-world communication | ||
| channels. We plan to do that alongside the implementation for this API. | ||
|
|
||
| ### Specifying a target world |
There was a problem hiding this comment.
Which means not specifying the target world in the future would default to the main world. If that is a downside or if explicitly specifying a target world right from the start is preferred specifying the target world right now world be good.
|
|
||
| ##### Injected script privileges | ||
|
|
||
| The injected script has the same privileges has other script in the main world. |
There was a problem hiding this comment.
| The injected script has the same privileges has other script in the main world. | |
| The injected script has the same privileges as other scripts in the main world. |
|
|
||
| ##### CSP Application | ||
|
|
||
| The injected script is not considered inline and does not have a corresponding |
There was a problem hiding this comment.
Would this also apply if JavaScript in general is disabled? With script-src set to "none" for example.
| @@ -0,0 +1,174 @@ | |||
| # Proposal: browser.dom.execute() | |||
There was a problem hiding this comment.
What is the motivation to use the dom namespace instead of the scripting namespace? Considering it's similarities with scripting.executeScript and the seemingly lack of connection with the DOM. Considering execute(), createPort() and also openOrClosedShadowRoot(), would it not make sense to use browser.document instead?
| * Appending a new script tag to the document | ||
|
|
||
| The former is heavily asynchronous or requires knowledge of whether to inject | ||
| beforehand (to register a script). The latter is very visible to the site and |
There was a problem hiding this comment.
The latter is also asynchronous, because the default CSP of content scripts in MV3 forbids inline script elements, leaving the only option to be <script src> with extension URL as src.
| ##### Return value serialization | ||
|
|
||
| Like arguments, the return value of the execution is serialized and | ||
| deserialized using the Structured Cloning algorithm. |
There was a problem hiding this comment.
| deserialized using the Structured Cloning algorithm. | |
| deserialized using the Structured Cloning algorithm. | |
| Thrown errors are also serialized using the Structured Cloning algorithm. | |
| When an input parameter or return value cannot be serialized, an error is thrown synchronously. | |
| Notably, `Promise` instanced such as returned by `async function` cannot be serialized. |
I elaborated on the serialization semantics. Although it would be nice to support Promise, I also recognize the complexity associated with supporting it, so I'm explicitly calling out non-support for Promise. I'm willing to consider support in the future, but note that a future expansion (dom.createPort proposal) also allows for async communication.
| **Summary** | ||
|
|
||
| This API allows an isolated world (such as a content script world or user | ||
| script world) to synchronously execute code in the main world of the document |
There was a problem hiding this comment.
Is this proposal limited to the main world? I was imagining this API to also be used from content scripts to execute in a user script world.
|
|
||
| ## Implementation Notes | ||
|
|
||
| N/A. |
There was a problem hiding this comment.
The whole proposal sketches this as a feature designed for isolated worlds. While the dom namespace is available to content scripts, it is not restricted to content scripts - regular extension documents can also access the API.
Should we restrict the availability of this new functionality to content scripts only, or do you want it to have the same availability as the current dom namespace?
| Arguments are serialized and deserialized using the Structured Cloning | ||
| algorithm. This allows for more flexibility than simply JSON conversion. In | ||
| the future, some arguments may have custom serialization. |
There was a problem hiding this comment.
Have the proposal authors considered whether arguments should support transferable objects?
This adds a proposal for a new dom.execute() method, which will allow synchronous execution in another "world" from a content script.