Playwright provides a set of APIs to automate Chromium, Firefox and WebKit browsers. By using the Playwright API, you can write scripts to create new browser pages, navigate to URLs and then interact with elements on a page.
Along with a test runner Playwright can be used to automate user interactions to validate and test web applications. The Playwright API enables this through the following primitives.
- Browser contexts
- Pages and frames
- Execution contexts: Playwright and Browser
- Evaluation Argument
A Browser refers to an instance of Chromium, Firefox or WebKit. Playwright scripts generally start with launching a browser instance and end with closing the browser. Browser instances can be launched in headless (without a GUI) or headful mode.
Launching a browser instance can be expensive, and Playwright is designed to maximize what a single instance can do through multiple browser contexts.
A BrowserContext is an isolated incognito-alike session within a browser instance. Browser contexts are fast and cheap to create. Browser contexts can be used to parallelize isolated test executions.
Browser contexts can also be used to emulate multi-page scenarios involving mobile devices, permissions, locale and color scheme.
A Browser context can have multiple pages. A Page refers to a single tab or a popup window within a browser context. It should be used to navigate to URLs and interact with the page content.
Read more on page navigation and loading.
A page can have one or more Frame objects attached to it. Each page has a main frame and page-level interactions (like
click) are assumed to operate in the main frame.
A page can have additional frames attached with the
iframe HTML tag. These frames can be accessed for interactions inside the frame.
Playwright can search for elements using CSS selectors, XPath selectors, HTML attributes like
data-test-id and even text content.
You can explicitly specify the selector engine you are using or let Playwright detect it.
All selector engines except for XPath pierce shadow DOM by default. If you want to enforce regular DOM selection, you can use the
*:light versions of the selectors. You don't typically need to though.
Learn more about selectors and selector engines here.
Some examples below:
Selectors using the same or different engines can be combined using the
>> separator. For example,
- wait for an element with the given selector to appear in the DOM
- wait for it to become visible: have non-empty bounding box and no
- wait for it to stop moving: for example, wait until css transition finishes
- scroll the element into view
- wait for it to receive pointer events at the action point: for example, wait until element becomes non-obscured by other elements
- retry if the element is detached during any of the above checks
You can explicitly wait for an element to appear in the DOM or to become visible:
... or to become hidden or detached
- page.click(selector[, options])
- page.fill(selector, value[, options])
- page.waitForSelector(selector[, options])
Playwright scripts run in your Playwright environment. Your page scripts run in the browser page environment. Those environments don't intersect, they are running in different virtual machines in different processes and even potentially on different computers.
document can be used in
If the result is a Promise or if the function is asynchronous evaluate will automatically wait until it's resolved:
Playwright evaluation methods like page.evaluate(pageFunction[, arg]) take a single optional argument. This argument can be a mix of Serializable values and JSHandle or ElementHandle instances. Handles are automatically converted to the value they represent.