[Feature] Enable background page access of browser extension in Firefox #2874
Comments
|
We would love to use this for testing Accessibility Insights for Web! |
#### Description of changes This PR is an experiment to try migrating our web e2e tests from Puppeteer to Playwright. We'll probably want to discuss it in Engineering Discussion before merging. [Playwright](https://playwright.dev/) is a relatively new (released 1.0 in January) competitor to Selenium/Puppeteer/Cypress, maintained by Microsoft and developed by a team that includes several ex-Puppeteer team members. Its API surface is very similar to Puppeteer's (note that there are very few changes to individual tests required in this migration PR), but it offers several advantages that are relevant to our project compared to Puppeteer: * Playwright's selectors pierce the shadow DOM by default (we needed to do some tricky workarounds for this with Puppeteer to test our target page visualizations) * Playwright's selectors are generally more flexible; they support xpath based queries, innertext-based queries, and even innertext+regex queries. The latter two require more effort with Puppeteer. * Playwright took a page out of Cypress's book and will, by default, wait for elements to be ["actionable"](https://playwright.dev/#version=v1.2.1&path=docs%2Factionability.md&q=) as a part of all its APIs which interact with elements on a page. This is a *big deal* for test reliability, and would allow us to obsolete a lot of our `Page` helpers that try to do similar actionability checks (but in a less complete/robust way than Playwright advertises). * Playwright's error messages are dramatically more actionable than Puppeteer's. For example, when I was doing this migration PR, there were a few tests in `visualization-boxes.test.ts` that were failing when they tried to look for the `#insights-shadow-host .insights-highlight-container` selector. In Puppeteer, this would have shown up in Jest logs as something like "Element not found", and it would have been up to you to figure out which element based on the stack. In Playwright, you still have the same stack info, but you additionally get this message which explains not only which element wasn't found, but context about *why* it wasn't found (in this case, that it was in the DOM but not yet visible as of the timeout): ``` TimeoutError: Timeout 5000ms exceeded during page.waitForSelector. ================ page.waitForSelector logs ================ [api] waiting for selector "#insights-shadow-host #insights-shadow-container" to be visible [api] selector resolved to hidden <div id="insights-shadow-container">…</div> ============================================================ Note: use DEBUG=pw:api environment variable and rerun to capture Playwright logs. ``` * Playwright's Firefox support is more complete (it is mostly-supported, but extension support requires workarounds; see microsoft/playwright#2644 and microsoft/playwright#2874 - Puppeteer's support for Firefox is currently experimental and much less complete) * Playwright maintains their own headful-browser-compatible docker base image, so we don't have to rely on Cypress's even though we aren't using Cypress * Playwright is written in Typescript, so its typings are included with the main npm package and cannot become out of date like `@types/puppeteer` #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: part of enabling e2e tests for #445 - [x] Ran `yarn fastpass` - [n/a] Added/updated relevant unit test(s) (and ran `yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] PR title *AND* final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See `CONTRIBUTING.md`. - [n/a] (UI changes only) Added screenshots/GIFs to description above - [n/a] (UI changes only) Verified usability with NVDA/JAWS
|
Really useful for decentralised apps using crypto wallet software like Joule, Meta Mask and Blockstack Connect! |
|
Support for extensions and bg pages is outside of the scope of Playwright. Is there a way to convert those great extensions into the code that works via Playwright? Playwright is more powerful than extensions in terms of accessing the page content and runtime, so all the a11y and performance auditing can be performed via Playwright interfaces as well. |
To clarify, I am a developer of the Accessibility Insights for Web extension looking to write end to end tests of our extension; I'm not looking to use the extension to audit a different product under test.
Playwright explicitly documents how to use it to test extensions in Chromium and even provides a specific ChromiumBrowserContext API for accessing backgroundPages. Are you saying that we should expect that functionality to go away or become deprecated? Or that it's in-scope for Chromium but not Firefox? The latter feels confusing; "Support for all browsers" is the top bullet point on Playwright's Why Playwright? page, it feels very inconsistent for there to be browser features that are in-scope for some browsers and out-of-scope for others.
As an extension developer, coercing our extension code to run outside of the context of a browser extension is a valuable methodology for some tests (eg, unit tests), but not for the kind of tests that I would want to use a browser automation tool like Playwright for! The primary value that Playwright adds for our testing is being able to test in the context that a user will see it. |
|
I think extension is valuable because we can test if page doesn't break with popular extension like ublock etc. Is there way to change default from extension off to extension on from our side? And yes crypto stuff works on extension and it can be useful there too. At least in puppeteer it used to work on ephemeral mode and well as non ephemeral mode I don't know why playwright doesn't support it :( |
|
@mukunduashok , I am an automation developer for browser extension using Puppeteer. As Puppeteer works for only Chromium browser.So I want to move my code to PlayWrite and checking for extensions support across browsers. With Chromium browser , PlayWrite works well with extensions. I want the same support for firefox as well. Is it possible ? Please help me out. |
@Saranya-v60 Currently playwright does not support 'Browser Extension' communication in Firefox. This ticket is raised as a feature request to enable "Background Pages" support in Firefox too. In case if you're looking for workaround, you can try out the steps mentioned by @aslushnikov in #2644 |
|
@dbjorge: you make a fair point. Our priority is the cross-browser web. Extensions are not a part of the web though, they are largely vendor-specific and hence are not a priority for us. The reason Chromium extensions support is there is organic. While working on Chrome DevTools, we designed all of its infrastructure, including the support for extensions. So for us, picking it up in Playwright was super-easy. Matching it in Firefox on the other hand is a substantial effort that is challenging to prioritize. We are happy to help reviewing the patches and driving it forward if someone wants to pick it up in the Firefox land. |
|
I am working on that kind of interop at present but for the mean while i have a proposal that is playwright related: shim the extension API so that it works in a normal opened playwright page that is not a real background page but who cares as long as the code runs and that would be maintainable as it is a 1:1 in most browsers the extension API it self matches while manifests and install pathes are the problems we can connect the background page to any other page and even fire the events that a extension would get as we have the same events in playwright when we open pages. |
Why was this issue closed?Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors. If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated. |
Let us know what functionality you'd like to see in Playwright and what is your use case.
It would be great, if we can access the background page of the browser extension as like in Chrome (https://playwright.dev/#version=v1.2.0&path=docs%2Fapi.md&q=working-with-chrome-extensions).
Do you think others might benefit from this as well?
Currently automation developers use web-sockets or other work around to enable communication between automation scripts and the browser extensions. This feature will enable many automation developers who work with browser extension to use same APIs to communicate with the background page of the extension.
The text was updated successfully, but these errors were encountered: