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.
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.
API reference#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.
API reference#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 id, 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,
Actions like page.click(selector, **kwargs) and page.fill(selector, value, **kwargs) auto-wait for the element to be visible and actionable. For example, click will:
visibility:hiddenYou can explicitly wait for an element to appear in the DOM or to become visible:
... or to become hidden or detached
API reference#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.
The page.evaluate(expression, **kwargs) API can run a JavaScript function in the context of the web page and bring results back to the Playwright environment. Browser globals like window and document can be used in evaluate.
If the result is a Promise or if the function is asynchronous evaluate will automatically wait until it's resolved:
Evaluation Argument#Playwright evaluation methods like page.evaluate(expression, **kwargs) 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.
Right:
Wrong:
API reference#RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4