[BUG] Component test fails on 2nd run when SSL is used
See original GitHub issueContext:
- Playwright Version:
"playwright/experimental-ct-svelte": "^1.24.2" - Operating System: macOS
- Node.js version: 16.14.2
- Browser: All
- Extra: ARM chip device
Code Snippet
Here’s the reduced test case which reproduces the issue: https://github.com/vhscom/playwright-ct-ssl-reduced-test
I’ve left the reduced test case configured with the Vite plugin for SSL but the issue can be reproduced without plugins specified in the Playwright component config file.
Describe the bug
This is an extension of https://github.com/microsoft/playwright/issues/16424. When testing a Svelte component using @vitejs/plugin-basic-ssl plugin test runner fails with error message when cache is present and unless the component under test has a timestamp modification (read: it was saved, even without changes):
undefined: net::ERR_EMPTY_RESPONSE at http://localhost:3100/playwright/index.html
=========================== logs ===========================
navigating to "http://localhost:3100/playwright/index.html", waiting until "load"
============================================================
I narrowed it down to a TLS/vite config/playwright lib corner case. It seems the URL under test does not work when the @vitejs/plugin-basic-ssl plugin is used—but only on the second run if the component under test doesn’t have a timestamp modification since the last cached run.
Ideally tests will either fail wholesale if SSL is configured or there will be a way to run component tests over the https scheme—which would be expected when the plug-in is configured via Playwright experimental ctViteConfig prop. Having test runs once, fail on the second run, then work again when the cache is cleared or the component timestamp changed is unexpected behavior.
Issue Analytics
- State:
- Created a year ago
- Comments:8 (5 by maintainers)

Top Related StackOverflow Question
Sweet—I’m going to assign this a milestone and owner to take a more holistic look to see if there’s something we can/should do differently, but at least there’s a workaround for you until then! (It may be resolved as Won’t Fix, but want another pair of eyes @pavelfeldman)
I’m trying something out. If it works, I’ll send you a diff.