Security News
vlt Debuts New JavaScript Package Manager and Serverless Registry at NodeConf EU
vlt introduced its new package manager and a serverless registry this week, innovating in a space where npm has stagnated.
playwright
Advanced tools
Playwright is a Node.js library developed by Microsoft that allows developers to automate browser actions for testing and scraping purposes. It supports multiple browsers, including Chromium, Firefox, and WebKit, and provides a high-level API to control headless or full browsers over the DevTools Protocol.
Browser Automation
Automate browser actions such as opening a page, clicking elements, and navigating through websites.
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
// other actions...
await browser.close();
})();
Web Scraping
Extract data from web pages by selecting elements and retrieving their content.
const { firefox } = require('playwright');
(async () => {
const browser = await firefox.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
const data = await page.textContent('.some-element');
console.log(data);
await browser.close();
})();
Automated Testing
Write automated tests for web applications, including assertions to validate the behavior of the application.
const { webkit } = require('playwright');
const { expect } = require('@playwright/test');
(async () => {
const browser = await webkit.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
const title = await page.title();
expect(title).toBe('Example Domain');
await browser.close();
})();
Cross-Browser Testing
Test web applications across multiple browsers to ensure compatibility and consistent behavior.
const { chromium, firefox, webkit } = require('playwright');
(async () => {
for (const browserType of [chromium, firefox, webkit]) {
const browser = await browserType.launch();
const page = await browser.newPage();
await page.goto('https://example.com');
// Perform tests across different browsers
await browser.close();
}
})();
Mobile Emulation
Emulate mobile devices to test responsive designs and touch interactions.
const { chromium, devices } = require('playwright');
const iPhone11 = devices['iPhone 11 Pro'];
(async () => {
const browser = await chromium.launch();
const context = await browser.newContext({
...iPhone11
});
const page = await context.newPage();
await page.goto('https://example.com');
// Emulate mobile device actions and layout
await browser.close();
})();
Selenium WebDriver is one of the most well-known browser automation tools. It requires separate drivers for each browser and is generally slower than Playwright due to its reliance on the WebDriver protocol, which is more standardized but less performant.
Puppeteer is another Node.js library that provides a high-level API to control Chrome or Chromium over the DevTools Protocol. It is similar to Playwright but was developed by the Chrome DevTools team and initially focused on Chrome, whereas Playwright supports multiple browsers out of the box.
Cypress is a front-end testing tool built for the modern web. It is both a library for writing tests and a test runner that executes the tests. Cypress is known for its rich interactive test runner interface but does not support as many browsers as Playwright and is primarily focused on testing rather than general browser automation.
Nightwatch.js is an automated testing framework for web applications and websites, written in Node.js and using the W3C WebDriver API. It is designed to simplify the process of writing end-to-end tests. Nightwatch is less feature-rich compared to Playwright and is more focused on the testing aspect.
Playwright is a Node library to automate the Chromium, WebKit and Firefox browsers. Playwright is focused on enabling cross-browser web automation platform that is ever-green, capable, reliable and fast. Our primary goal with Playwright is to improve automated UI testing by eliminating flakiness, improving the speed of execution and offering insights into the browser operation. Playwright runs headless versions of these browsers by default, but can be configured to run the full versions.
npm i playwright
This installs Playwright along with its dependencies and the browser binaries. Browser binaries are about 50-100MB each, so expect the installation network traffic to be substantial.
Playwright can be used to create a browser instance, open pages, and then manipulate them. See API docs for a comprehensive list.
This code snippet navigates to example.com in WebKit, and saves a screenshot.
const pw = require('playwright');
(async () => {
const browser = await pw.webkit.launch(); // or 'chromium', 'firefox'
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://www.example.com/');
await page.screenshot({ path: 'example.png' });
await browser.close();
})();
This snippet emulates Mobile Safari on a device at a given geolocation, navigates to maps.google.com, performs action and takes a screenshot.
const pw = require('playwright');
const iPhone11 = pw.devices['iPhone 11 Pro'];
(async () => {
const browser = await pw.webkit.launch();
const context = await browser.newContext({
viewport: iPhone11.viewport,
userAgent: iPhone11.userAgent,
geolocation: { longitude: 12.492507, latitude: 41.889938 },
permissions: { 'https://www.google.com': ['geolocation'] }
});
const page = await context.newPage('https://maps.google.com');
await page.click('text="Your location"');
await page.waitForRequest(/.*preview\/pwa/);
await page.screenshot({ path: 'colosseum-iphone.png' });
await browser.close();
})();
And here is the same script for Chrome on Android.
const pw = require('playwright');
const pixel2 = pw.devices['Pixel 2'];
(async () => {
const browser = await pw.chromium.launch();
const context = await browser.newContext({
viewport: pixel2.viewport,
userAgent: pixel2.userAgent,
geolocation: { longitude: 12.492507, latitude: 41.889938 },
permissions: { 'https://www.google.com': ['geolocation'] }
});
const page = await context.newPage('https://maps.google.com');
await page.click('text="Your location"');
await page.waitForRequest(/.*pwa\/net.js.*/);
await page.screenshot({ path: 'colosseum-android.png' });
await browser.close();
})();
This code snippet navigates to example.com in Firefox, and executes a script in the page context.
const pw = require('playwright');
(async () => {
const browser = await pw.firefox.launch(); // or 'chromium', 'webkit'
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://www.example.com/');
const dimensions = await page.evaluate(() => {
return {
width: document.documentElement.clientWidth,
height: document.documentElement.clientHeight,
deviceScaleFactor: window.devicePixelRatio
}
})
console.log(dimensions);
await browser.close();
})();
Check out our contributing guide.
Q: How does Playwright relate to Puppeteer?
We are the same team that built Puppeteer. Puppeteer proved that there is a lot of interest in the new generation of ever-green, capable and reliable automation drivers. With Playwright, we'd like to take it one step further and offer the same functionality for all the popular rendering engines. We'd like to see Playwright vendor-neutral and shared goverened.
With Playwright, we are making the APIs more testing-friendly as well. We are taking the lessons learned from Puppeteer and incorporate them into the API, for example, user agent / device emulation is set up consistently on the BrowserContext
level to enable multi-page scenarios, click
waits for the element to be available and visible by default, there is a way to wait for network and other events, etc.
Playwright also aims at being cloud-native. Rather than a single page, BrowserContext
abstraction is now central to the library operation. BrowserContext
s are isolated, they can be either created locally or provided as a service.
All the changes and improvements above would require breaking changes to the Puppeteer API, so we chose to start with a clean slate instead. Due to the similarity of the concepts and the APIs, migration between the two should be a mechanical task.
Q: What about the WebDriver?
We recognize WebDriver as a universal standard for the web automation and testing. At the same time we were excited to see Puppeteer affect the WebDriver agenda, steer it towards the bi-directional communication channel, etc. We hope that Playwright can take it further and pioneer support for numerous PWA features across the browers as they emerge:
[capabilities] With Playwright, we aim at providing a more capable driver, including support for mobile viewports, touch, web & service workers, geolocation, csp, cookie policies, permissions, accessibility, etc.
[ergonomics] We continue the trend set with Puppeteer and provide ergonomically-sound APIs for frames, workers, handles, etc.
[reliability] With Playwright, we encourage setTimeout
-free automation. The notion of the wall time is incompatible with the operation in the cloud / CI. It is a major source of flakiness and pain and we would like to provide an alternative. With that, Playwright aims at providing sufficient amount of events based on the browser instrumentation to make it possible.
Q: What browser versions does Playwright use?
Chromium: Playwright uses upstream versions of Chromium. When we need changes in the browser, they go into the browser directly and then we roll our dependency to that version of Chromium. As of today, we update Chromium as needed or at least once a month. We plan to synchronize our npm release cycle with the Chromium stable channel cadence.
WebKit: Playwright makes a number of modifications to WebCore
and WebKit2
in order to extend WebKit's remote debugging capabilities and support the full set of Playwright APIs. It also modifies the Minibrowser
embedders to allow headless operation and headful debugging on all platforms. We use WebKit2 in a modern process isolation mode, enable mobile viewport, touch and geolocation on non-iOS platforms, etc. etc.
We'd like to switch to the upstream-first mode of operation, so we will be offering all of the WebKit patches for review upstream. Until then, they can be found in the browser_patches/webkit
folder.
Firefox: Playwright makes a number of modifications to Firefox as well. Those are adding support for content script debugging, workers, CSP, emulation, network interception, etc. etc.
Similarly to WebKit, we'd like to offer all of those for review upstream, for now they can be found in the browser_patches/firefox
folder.
Q: Is Playwright ready?
Playwright is ready for your feedback. It respects semver, so please expect some API breakages as we release 1.0. All we can promise is that those breakages are going to be based on your feedback with the sole purpose of making our APIs better.
Playwright is being actively developed as we get to the feature parity across Chromium, Firefox and WebKit. Progress on each browser can be tracked on the Is Playwright Ready? page, which shows currently failing tests per browser.
FAQs
A high-level API to automate web browsers
The npm package playwright receives a total of 5,084,927 weekly downloads. As such, playwright popularity was classified as popular.
We found that playwright demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 4 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
vlt introduced its new package manager and a serverless registry this week, innovating in a space where npm has stagnated.
Security News
Research
The Socket Research Team uncovered a malicious Python package typosquatting the popular 'fabric' SSH library, silently exfiltrating AWS credentials from unsuspecting developers.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.