Filling Text Inputs and Textareas
locator.fill('Kohli') clears the input and sets its value in a single, near-instantaneous operation, dispatching an input event but not individual keydown/keyup events for each character. locator.pressSequentially('Kohli') instead types one character at a time, firing real keyboard events for each keystroke. Most forms work fine with fill(), but any field that reacts to individual keystrokes — an autocomplete dropdown, a masked input like a credit-card formatter, or a live character counter — needs pressSequentially() to trigger correctly, since fill() alone won't fire the per-key events those widgets listen for.
Cricket analogy: locator.fill('Kohli') instantly sets the whole name in one motion, like a scorer directly writing the final total on the board — but pressSequentially types letter by letter with real key events, closer to live ball-by-ball commentary needed when an autocomplete dropdown, like a player-name suggester, must react to each keystroke.
// fill() sets the value directly - fine for plain inputs
await page.getByLabel('Full name').fill('Virat Kohli');
// pressSequentially() fires real keydown/keyup events per character -
// required for autocomplete widgets that listen to each keystroke
await page.getByLabel('City').pressSequentially('Mumb');
await page.getByRole('option', { name: 'Mumbai' }).click();Checkboxes, Radio Buttons, and Selects
check() and uncheck() are idempotent: calling check() on an already-checked checkbox does nothing further, and calling it on an unchecked one checks it, so you never accidentally toggle a box into the wrong state by calling the method twice — a real risk if you used click() instead. selectOption() targets a native <select> element and can pick by value, by visible label, or by index, all without needing to simulate opening a dropdown UI. Custom dropdown components built from styled <div> elements — React-select, MUI Autocomplete, and similar libraries — are not real <select> tags, so selectOption() does not work on them; those require clicking the trigger and then clicking the visible option, exactly as a user would.
Cricket analogy: check() is idempotent, like a scorer marking a batter as 'out' — doing it twice doesn't create a double dismissal, it simply confirms the same state; likewise selectOption('T20') on a format dropdown sets the value directly, without needing to simulate opening the dropdown UI.
check() and uncheck() throw an error if the target element does not have the role of checkbox or radio — this is a deliberate guardrail that prevents you from accidentally calling them on a plain <div> styled to look like a checkbox but lacking the correct semantics.
Uploading Files
locator.setInputFiles('path/to/resume.pdf') attaches a file directly to an <input type="file"> element, accepting a single path, an array of paths for multi-file inputs, or an in-memory buffer with { name, mimeType, buffer } for files generated on the fly. Critically, this works even when the actual file input is visually hidden behind a styled 'Upload Resume' button — a very common real-world pattern — because setInputFiles() sets the input's value directly rather than requiring you to click a button and interact with the native OS file-picker dialog, which Playwright cannot drive at all.
Cricket analogy: setInputFiles() hands Playwright the exact scorecard file to upload directly, like a curator submitting the official match report straight to the scoring system without a physical courier — it works even when the file input is visually hidden behind a styled 'Upload Scorecard' button.
Submitting Forms and Handling Validation
A form can be submitted either by clicking a submit button with getByRole('button', { name: 'Submit' }).click() or by pressing Enter inside a text field via locator.press('Enter'), and both trigger the same submit event on native <form> elements. After submitting, the test must wait for the actual consequence — a navigation with page.waitForURL(), a specific network response with page.waitForResponse(), or a success/error message becoming visible — rather than asserting immediately, since the submission is asynchronous. Client-side validation should be checked directly: look for aria-invalid="true" on the offending field or assert that a visible error message locator is present before assuming a submission failed or succeeded.
Cricket analogy: Clicking 'Submit' and immediately checking the URL is like declaring the match result the instant the ball is bowled, before the umpire signals — you must await the actual navigation or network response first, the way a scorer waits for the umpire's confirmed signal.
A common race condition: clicking Submit and immediately asserting the URL or a success message without first awaiting page.waitForURL() or page.waitForResponse(). Since the submission is asynchronous, the assertion may run before the server has responded, producing intermittent, environment-dependent failures.
- fill() sets a value instantly; pressSequentially() types character by character and fires real key events, needed for autocomplete or masked inputs.
- check() and uncheck() are idempotent and throw an error on non-checkbox/radio elements.
- selectOption() only works on native <select> elements, not custom div-based dropdown widgets.
- setInputFiles() attaches files directly to a file input, even when it's visually hidden, without touching the native OS dialog.
- Forms can be submitted via a button click or Enter key press inside a text field.
- Always await the real consequence of a submission (navigation, response, or visible message) rather than asserting immediately.
- Check aria-invalid or visible error message locators to verify client-side validation state.
Practice what you learned
1. When should you use pressSequentially() instead of fill()?
2. Why is check() safer than click() for toggling a checkbox to a known state?
3. Why doesn't selectOption() work on a React-select or MUI Autocomplete dropdown?
4. What is the risk of asserting a URL change immediately after clicking a form's Submit button?
Was this page helpful?
You May Also Like
Locators: getByRole, getByText, and CSS
Learn how Playwright locators find elements using role-based, text-based, and CSS selector strategies, and why role-based locators are the recommended default.
Auto-Waiting and Actionability Checks
Understand how Playwright automatically waits for elements to become actionable before interacting with them, eliminating most manual sleeps and flaky waits.
Assertions with expect()
Learn Playwright's web-first assertions — how expect(locator) auto-retries until conditions are met, and how that differs from generic value assertions.