Commit 3841144
iwsdk-vite-plugin-dev: use waitUntil:'commit' for managed-browser navigation
Summary:
`launchManagedBrowser` in `packages/vite-plugin-dev/src/headless-browser.ts` previously did `page.goto(url, { waitUntil: 'networkidle' })` followed immediately by `page.waitForFunction(() => window.IWER_DEVICE !== undefined, { timeout: 15000 })`.
`networkidle` is a heuristic — it resolves once Playwright observes >=500ms with no network activity. The IWSDK dev runtime opens a persistent WebSocket to `/__iwer_mcp` on load, and on Chromium builds where WebSocket frames count toward network activity (notably Playwright's fallback ubuntu-24.04-x64 chromium build), `networkidle` never fires. `page.goto` then times out at 30s with `browser_launch_failed`, even though the page reached `interactive` and IWER injected within ~800ms.
Switch to `waitUntil: 'commit'`. The subsequent `waitForFunction(IWER_DEVICE)` is the real readiness gate — it polls until the IWSDK dev runtime has finished injecting. No code between the two relies on intermediate `goto` state, so the caller's guarantee when `launchManagedBrowser` returns is unchanged.
`commit` + explicit `waitForFunction` is a more deterministic readiness contract than `networkidle` + same explicit wait: total wall-clock is identical on environments where `networkidle` was already firing (the explicit wait was the long pole), and it removes a class of "browser launches fine but `page.goto` times out" failures that are non-obvious to debug.
Reviewed By: zjm-meta
Differential Revision: D105639703
fbshipit-source-id: bcac4cb66896ca2fb09dd899e77044ece4f8e0d11 parent 2639700 commit 3841144
1 file changed
Lines changed: 1 addition & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
373 | 373 | | |
374 | 374 | | |
375 | 375 | | |
376 | | - | |
| 376 | + | |
377 | 377 | | |
378 | 378 | | |
379 | 379 | | |
| |||
0 commit comments