-
Notifications
You must be signed in to change notification settings - Fork 9k
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
feat: extension execution contexts #2812
Conversation
#### executionContext.name() | ||
- returns: <[string]> A human readable name for the execution context. | ||
|
||
Most execution contexts have an empty string for a name. Execution contexts created by extensions will have the title of the extension as thier name. |
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.
thier -> their :)
@@ -1116,6 +1131,9 @@ puppeteer.launch().then(async browser => { | |||
|
|||
``` | |||
|
|||
#### page.extensionContexts() |
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 like restricting us to extensions. Execution contexts can exist and might be handy in non-chromium embedders, e.g. in headless.
From this point of view, the ideal API would be like this:
// ExecutionContext lifecycle
page.on('executioncontextcreated');
page.on('executioncontextdestroyed');
// Querying contexts
const contexts = frame.executionContexts();
const context = frame.defaultExecutionContext();
// Inspecting context
context.name(); // returns extension name, if any
context.isDefault(); // returns `true` if this is a default execution context
The only downside here is that we already have frame.executionContext()
instead of frame.defaultExecutionContext()
. I think we can keep it like this for now, and rename it later on in the API cleanup for v2.0.
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.
An api that contains all execution contexts is reasonable, but id still want helper methods specifically for extension contexts.
I’m wary of releasing an api that will today be effectively only extension contexts, but in the future might contain some more exotic contexts.
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.
An api that contains all execution contexts is reasonable, but id still want helper methods specifically for extension contexts.
I'd move slowly into this direction. For the first-class extension support, we'll need to have an Extension
class - there you might have methods like extension.contentScript(frame)
and others.
Closing this in favor of #2812 (comment) |
This patch exposes frame's execution contexts, making it possible to debug extension's content scripts. This is a resurrected puppeteer#2812.
This patch exposes frame's execution contexts, making it possible to debug extension's content scripts. This is a resurrected #2812.
No description provided.