-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Description
I've recently been looking in to testing WebExtensions (e.g #2486). With the action.openPopup API, it's possible to trigger the extension popup by running code from the background page. This causes a new context to load which it would be useful to be able to automate.
Using the following, it actually is possible to get a reference to the new target:
const popup = await browser.waitForTarget(
(target) =>
target.type() === "other" &&
target.url() === `chrome-extension://${extensionId}${path}`
);However, calling target.page() returns null because the type is other:
puppeteer/packages/puppeteer-core/src/common/Browser.ts
Lines 217 to 227 in 1bbecb3
| #setIsPageTargetCallback(isPageTargetCallback?: IsPageTargetCallback): void { | |
| this.#isPageTargetCallback = | |
| isPageTargetCallback || | |
| ((target: Protocol.Target.TargetInfo): boolean => { | |
| return ( | |
| target.type === 'page' || | |
| target.type === 'background_page' || | |
| target.type === 'webview' | |
| ); | |
| }); | |
| } |
Of course, this does make sense and the best solution would be accommodating extension testing in the Chrome Dev Tools protocol by returning a new "popup" type. At least one relevant issue is likely this one: https://crbug.com/1223710
In the meantime, however, removing the _isPageTargetCallback check does give you a page which can be automated! It sounds like some features are missing - #1215 (comment) - so exposing this should likely not be the default. That said, in my short amount of testing it seems to work well enough that allowing developers a way of experimenting with this functionality without needing to entirely fork Puppeteer may be desirable.