18 Playwright File, Dialog, and Browser Event Interview Scenarios

Browser-event interviews test race awareness and artifact ownership. Uploads, downloads, popups, dialogs, console errors, and failed requests all happen outside the simple sequence of "click, then inspect." A candidate who registers an observer after the trigger can write code that passes locally and waits forever in CI.

The scenarios below require more than event syntax. Explain when the observer starts, whether it is one-shot or ongoing, who handles the event, how the resulting artifact is validated, and how listeners and temporary files are released. That lifecycle is the senior-level signal.

Use the Event Before Trigger Rule

Playwright's event guide distinguishes waiting for one event from subscribing to a stream of events. The safe scenario pattern is to register the promise or handler, perform the user trigger, await the captured event, and then validate or handle it. The order matters even when the code runs in one test function.

The observer should be as narrow as the requirement. A permanent page listener is not a stronger solution to a one-time download; it creates lifecycle work and can capture unrelated events.

Event Ordering and Listener Scope

1. Why do you create an event promise before clicking the trigger?

The event may fire before the click promise resolves. Creating the waiter first ensures Playwright is listening at the moment the browser emits it. I usually store the promise, perform the action, then await the promise; I do not await the event before triggering it. The resulting sequence is deterministic and makes the relationship between cause and event obvious in review.

2. When should you use waitForEvent instead of page.on?

Use waitForEvent for one expected occurrence tied to a scenario, such as a download caused by one button. Use page.on for ongoing observation such as collecting console messages. Ongoing listeners need a stored handler, bounded data, and teardown. A one-shot wait naturally completes and is easier to attribute. I would not add a permanent listener solely to avoid promise ordering.

Upload and File Chooser Scenarios

3. Why is setInputFiles usually better than automating the operating system picker?

The system picker is outside the browser page and varies by platform. setInputFiles assigns files to the HTML input and exercises the application's change handling, validation, upload request, and response. It is faster and reproducible. The test should still assert the visible filename or upload outcome. Native picker appearance belongs to platform integration coverage, not ordinary web automation.

4. How would you upload through a hidden file input?

If the page exposes an input tied to a visible Upload control, I would locate that input by a stable contract and call setInputFiles; it does not need to be visibly clickable. I would avoid changing CSS or forcing the visible control. If the input is created only after the control is clicked, handle the filechooser event instead. The answer depends on actual DOM behavior.

5. How would you test an upload without committing a fixture file?

Playwright can provide an in-memory file payload with a name, MIME type, and buffer. This is useful for precise boundary data and avoids repository clutter. I would keep the bytes realistic enough for the application's parser and assert server or UI acceptance. A declared MIME type alone does not make invalid bytes a valid image or document.

await page.getByLabel('Upload report').setInputFiles({
  name: 'summary.csv',
  mimeType: 'text/csv',
  buffer: Buffer.from('case,status\nQA-42,passed\n'),
})

await expect(page.getByText('summary.csv uploaded')).toBeVisible()

6. How would you handle a custom button that opens a file chooser?

Register page.waitForEvent('filechooser') before clicking the custom button, then set files on the returned chooser. This avoids searching for an input the component may create dynamically. I would assert the selected file and final upload state. If no chooser appears, the trace and DOM should reveal whether the button was disabled, intercepted, or implemented without a real file input.

Download Capture and Artifact Validation

7. How would you capture a download without missing a fast event?

Create the download promise before clicking Export, then await the returned Download object. The official download guidance uses this ordering. I would not rely on watching a filesystem directory because download paths and timing are browser-managed. The object provides the suggested filename and controlled ways to save or inspect the artifact.

const downloadPromise = page.waitForEvent('download')
await page.getByRole('button', { name: 'Export CSV' }).click()
const download = await downloadPromise

expect(download.suggestedFilename()).toBe('orders.csv')
await download.saveAs(testInfo.outputPath('orders.csv'))

8. Why is asserting suggestedFilename alone insufficient?

It proves only the browser's proposed name, not that the content is complete or correct. A server error page can be downloaded under a plausible filename. I would inspect bytes or parse the format, then assert key headers, records, signatures, or archive entries. Filename should be asserted only if naming is part of the requirement; otherwise content and successful completion are stronger evidence.

9. How would you validate a large download without loading all bytes into memory?

Stream the downloaded content or save it to the test's output directory, then process it incrementally with an appropriate parser or hash. I would enforce a reasonable test-specific size boundary and report safe metadata. Exact file comparison can be brittle when timestamps or ordering vary, so validate the stable contract. The temporary artifact remains owned by the test output lifecycle.

10. How would you diagnose a download event that fires but produces no usable file?

Inspect download.failure(), response headers, authentication, server logs or correlation IDs, and whether the context closed before completion. I would avoid reading a path before the download finishes. The UI may have started a download while the backend returned an error. The failure report should distinguish browser cancellation, network failure, and invalid content instead of reducing all three to a missing file assertion.

Dialog Handling and Blocking Behavior

11. What happens when a page opens a dialog and no listener is installed?

Playwright dismisses dialogs automatically when no handler is registered, allowing the action to proceed. That default is convenient only when the dialog is irrelevant. If the scenario must verify message or acceptance behavior, install a handler before the trigger. A candidate should not claim a test always hangs on unhandled dialogs; the hang risk appears when a listener exists but does not handle the dialog.

12. Why can a logging-only dialog listener make click hang?

Browser dialogs block page execution. Once a listener is attached, the test owns the decision to accept or dismiss. Logging the message without either action leaves the browser blocked, so the click that triggered it cannot complete. The dialog documentation calls out this responsibility. I would handle the dialog inside the registered callback and assert its message safely.

13. How would you test a prompt that requires input?

Register a one-time dialog wait or handler before the trigger, assert that its type and message match the expected prompt, and accept it with the controlled value. Then verify the page or server outcome. I would avoid a broad permanent handler that accepts every prompt, because an unexpected security or confirmation dialog could be silently approved.

const dialogPromise = page.waitForEvent('dialog')
await page.getByRole('button', { name: 'Rename project' }).click()
const dialog = await dialogPromise

expect(dialog.type()).toBe('prompt')
expect(dialog.message()).toContain('New project name')
await dialog.accept('Release verification')
await expect(page.getByRole('heading', { name: 'Release verification' })).toBeVisible()

14. How would you test a beforeunload confirmation?

I would trigger navigation or page close with the appropriate run-before-unload behavior, register dialog handling first, and assert the resulting choice. Browser-provided dialog text can be browser-specific, so focus on dialog type and application outcome unless exact text is controlled. Accepting means leaving; dismissing means staying. The test must avoid waiting for navigation when it intentionally dismisses the unload.

Diagnostic Browser Events

15. How would you collect console messages without leaking them into later tests?

Attach a named handler to the test-scoped page, collect only needed levels and bounded text, and remove it in teardown if the fixture outlives the immediate scope. Attach messages on failure rather than printing everything. I would redact tokens and personal data. Worker-scoped global collectors are risky because they can mix pages, retain objects, and produce duplicated output after retries.

16. Why should pageerror be captured separately from console error?

An uncaught exception emitted as pageerror and a script calling console.error are different signals. Capturing both preserves diagnosis. I would decide which errors fail the test through an allowlist or explicit assertion, because third-party noise may exist. The report should include message and safe stack context without turning every unrelated console statement into a product regression.

17. Why does requestfailed not report ordinary HTTP error statuses?

An HTTP response with a failure status still completed at the network level, so it is observed as a response. requestfailed represents a request that could not complete, such as a connection or transport failure. I would listen to responses for status policies and request failures for transport diagnosis. Conflating them misses server errors and produces the wrong remediation path.

Event Architecture and Review

18. How would you review a fixture that registers many anonymous page listeners?

I would inventory which listener supports which failure diagnosis, replace anonymous callbacks with named removable handlers, bound collected data, and scope them to the test or context that owns the pages. One-shot scenario events move back into tests as promises. Teardown removes ongoing listeners and attachments are created only when useful. This reduces memory retention and prevents events from one test appearing in another test's report.

Event Handling Checklist

• Register one-shot waits before the action that can emit the event.
• Choose direct input assignment or file chooser handling from the real DOM behavior.
• Validate downloaded content, not merely event arrival or filename.
• Handle every dialog when a listener is installed.
• Keep ongoing listeners named, bounded, scoped, and removable.
• Separate transport failures, HTTP errors, console output, and uncaught exceptions.
• Save artifacts under per-test output ownership and avoid secret-bearing attachments.

Conclusion: Own the Event From Observation to Cleanup

Reliable browser-event tests begin listening before they act and finish by validating the event's real consequence. Upload bytes must produce an accepted file, a download must contain the required artifact, and a dialog listener must resolve the browser's blocked state. One-shot promises belong close to their triggers; ongoing listeners need explicit teardown. That complete lifecycle turns a timing-sensitive browser signal into deterministic, reviewable evidence.