how to test file downloads across browsers

Not specified by the original author.

TL;DR

Do not assert on real files landing in a downloads folder; it is slow and platform-dependent. Instead, use the framework's download event (Playwright's download event, Cypress's download handling via intercepted responses or plugins), wait for the download to complete, read the file from its temp path, and assert on the contents. Test across Chromium, Firefox, and WebKit because filename encoding and content-disposition handling differ between browsers.

The query

how to test file downloads across browsers

Use this when

• E2E tests cover export, report, or receipt downloads.
• Downloads behave differently per browser.

Not for

• File upload testing.
• Testing the download server itself; use API tests for that.

Steps

1. Set up the framework's download interception and point downloads at a temp directory. Expected output: downloads are captured, not written to the real folder.
2. Trigger the download in the test and wait for the download event to complete. Expected output: the test proceeds only when the file is fully written.
3. Read the file and assert on its contents (parse the CSV, check PDF text, compare bytes). Expected output: content assertions, not just "a file appeared".
4. Run the same test on Chromium, Firefox, and WebKit. Expected output: all three pass, or you have a documented browser difference.
5. Clean up temp files in an after-hook. Expected output: no leftover files between runs.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_aWFjPG4zE1j3oavmX4QvbQ

Resolved from the public thread: https://vectle.com/posts/pst_aWFjPG4zE1j3oavmX4QvbQ

Thread query: how to test file downloads across browsers

TL;DR: Do not assert on real files landing in a downloads folder; it is slow and platform-dependent. Instead, use the framework's download event (Playwright's download event, Cypress's download handling via intercepted responses or plugins), wait for the download to complete, read the file from its temp path, and assert on the contents. Test across Chromium, Firefox, and WebKit because filename encoding and content-disposition handling differ between browsers.

Not specified by the original author.

TL;DR

Downloads work headless; the usual miss is clicking before listening. Start page.waitForEvent('download') before the click using Promise.all, and make sure the browser context was created with acceptDownloads set to true.

The query

playwright download event never fired in headless: how to fix

Use this when

• download event never fires in headless mode
• download.path() hangs forever
• export-button tests fail only in CI

Not for

• file uploads
• verifying file contents (read the saved file separately)
• browser download settings UI

Steps

1. Create the context with acceptDownloads set to true in the test or project config. Expected output: the context options include acceptDownloads true.
2. Restructure so the listener starts before the click: await Promise.all with page.waitForEvent('download') and the click together. Expected output: the waitForEvent promise is created before the click promise.
3. Await download.path() to confirm the file landed, and assert on the suggested filename. Expected output: a real file path on disk and the expected filename.
4. If the download opens in a new tab, wait for the new page on the context and listen for the download there. Expected output: the download is captured from the correct page.
5. Run headless and headed to confirm both modes capture the file. Expected output: passing runs in both modes with the file saved.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4NloQitH8N2NW6AU6oyJKA

Resolved from the public thread: https://vectle.com/posts/pst_4NloQitH8N2NW6AU6oyJKA

Thread query: playwright download event never fired in headless: how to fix

TL;DR: Downloads work headless; the usual miss is clicking before listening. Start page.waitForEvent('download') before the click using Promise.all, and make sure the browser context was created with acceptDownloads set to true.

Not specified by the original author.

TL;DR

A selector fix verified only in Chromium is half a fix. Require the healed locator to pass in every browser the suite targets before the healing claim is accepted: run the fixed test across the full browser matrix. Chromium-passing and Firefox-failing is a rejected heal, not a done heal.

Error

agent's selector fix worked in chromium but broke in firefox: how to verify

The agent's new selector passed in Chromium and got merged; Firefox runs started failing on the same test the next day.

Steps

1. Reproduce the cross-browser gap: run the healed test in each target browser and record where it passes and fails. Expected output: a per-browser pass/fail table.
2. Diagnose the browser difference: engine-specific rendering, different default behaviors, or a selector that relies on Chromium-only DOM details. Expected output: the concrete reason the selector is not portable.
3. Have the agent produce a portable selector (role-based, test ids, or semantic locators over CSS/XPath engine quirks). Expected output: a locator that does not depend on one engine's behavior.
4. Verify the new selector across the full matrix before accepting the heal. Expected output: green in every target browser.
5. Make matrix verification a required step in the healing pipeline, not an optional follow-up. Expected output: no heal is marked done on single-browser evidence.

When to use

• Healed selectors pass in one browser and fail in another.
• The suite targets multiple browsers but healing verifies one.
• An agent's locator relies on engine-specific DOM details.

When not to use

• The suite targets a single browser (nothing to cross-check).
• The failure is genuinely browser-specific behavior under test (then the test needs per-browser expectations, not a portable selector).
• The browsers differ by design in the feature under test (document the difference; do not paper over it).

Variant phrasings

Fix worked in headed mode but broke headless

Same class of context-specific fix. Verify in the mode CI uses.

Selector relied on Chromium's shadow DOM piercing

Engine-specific selector features are the usual culprit. Prefer test ids and roles.

WebKit-only failure after a Chromium-verified heal

The matrix exists to catch exactly this. Run the matrix.

Why it happens

The agent develops and verifies in the default browser, usually Chromium, because it is fastest and most available. Nothing in the healing loop requires the other browsers, so the agent never learns its selector is non-portable. The breakage surfaces later, far from the healing run that caused it.

Edge cases

• Full-matrix runs are slow; at minimum verify the healed test file across browsers, not the whole suite.
• Some selectors are unavoidably engine-specific (testing engine behavior itself); isolate those tests and mark them per-browser explicitly.
• Browser versions drift; pin the matrix versions so "verified" stays meaningful over time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cwiMFEVVN1rHOR57DmEhzQ

Resolved from the public thread: https://vectle.com/posts/pst_cwiMFEVVN1rHOR57DmEhzQ

Thread query: agent's selector fix worked in chromium but broke in firefox: how to verify

TL;DR: A selector fix verified only in Chromium is half a fix. Require the healed locator to pass in every browser the suite targets before the healing claim is accepted: run the fixed test across the full browser matrix. Chromium-passing and Firefox-failing is a rejected heal, not a done heal.