Describe the bug
The --timeout CLI flag and export.timeout frontmatter config are ignored for a critical part of the export process, causing exceptionally bulky slides to always fail after exactly 30 000 ms regardless of the
configured timeout.
Root cause: in exportSlides(), timeout is in scope and correctly passed to page.goto() and page.waitForLoadState(), but the subsequent frame loop uses Playwright's hardcoded 30 s default:
// export-*.mjs ~line 163
const frames = page.frames();
await Promise.all(frames.map((frame) => frame.waitForLoadState()));
// ^^^^ timeout never forwarded
Large presentations with many slides, complex components (Monaco editors, Mermaid diagrams, embedded iframes), or slow network conditions can easily exceed 30 s to fully render. Users who set --timeout 60000 or
export: { timeout: 60000 } in their frontmatter reasonably expect this to work end-to-end — but it has no effect on this code path.
Proposed fix
await Promise.all(frames.map((frame) =>
frame.waitForLoadState(void 0, { timeout }))
));
Minimal reproduction
1. Create a new project: npm create slidev@latest
2. Add download: true and export: { timeout: 60000 } to the frontmatter
3. Run slidev build on a large presentation (or throttle the network in DevTools)
4. Export fails after exactly 30 000 ms — the configured timeout has no effect
Environment
- Slidev version: 52.15.0
- Browser: N/A (Playwright Chromium headless)
- OS: macOS 26.4.1, Node v24.15.0
Describe the bug
The
--timeoutCLI flag andexport.timeoutfrontmatter config are ignored for a critical part of the export process, causing exceptionally bulky slides to always fail after exactly 30 000 ms regardless of theconfigured timeout.
Root cause: in
exportSlides(),timeoutis in scope and correctly passed topage.goto()andpage.waitForLoadState(), but the subsequent frame loop uses Playwright's hardcoded 30 s default: