fix(preview): async WebView2 creation on Windows — root fix for #149 by Tryanks · Pull Request #253 · Tryanks/tcode

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks · 2026-08-22T15:52:14Z

Root cause (reproduced deterministically on physical Windows 11)

--preview-smoke died at drop-during-create on 3/3 runs: process exit code 0 mid-phase, no dump, no PASS. wry's synchronous build_as_child waits for WebView2's async environment/controller creation by running a nested Win32 message pump on the GPUI UI thread (webview2_com::wait_with_pump). A window-teardown message dispatched inside that pump destroys the last window → GPUI exits the process mid-creation. Timing-dependent variants can AV (parent HWND destroyed under the pending controller). macOS passes the same harness — the pump semantics differ.

Fix

Windows: build_as_child_async (no nested pump; ships in lb-wry 0.53.3) driven by the GPUI foreground executor, behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Completion installs the view only if window + panel + exact creation generation all still live; otherwise the raw webview is dropped via a panic-guarded helper. Duplicate ensures coalesce; navigations replay from the stored URL; value-returning MCP ops answer a retryable "preview is starting" error; builder failures keep the existing unavailable-state path.
UDF hardening: shared WebContext pins the WebView2 user-data folder under the tcode data dir (%APPDATA%\tcode\WebView2 or %TCODE_DATA_DIR%\WebView2) instead of the crash-prone exe-adjacent default.
macOS unchanged (proven synchronous path).
Harness upgraded to prove it: drop-during-create asserts an actually in-flight creation before dropping the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so a premature exit is observable as a missing PASS.

Verification

macOS: full --preview-smoke run — all 10 phases + PASS (output in the commit/report).
Windows cross-check: cargo clippy -p tcode --target x86_64-pc-windows-gnu -- -D warnings — pass.
Physical Windows 11 validation before merge: dev-build artifact will run the same harness under procdump on real hardware; results will be posted here.
Gates: fmt / clippy -D warnings / full workspace tests — green locally.

Closes#149

🤖 Generated with Claude Code

…the UI thread Root cause of #149, reproduced deterministically on physical Windows 11: wry's synchronous build_as_child pumps a nested Win32 message loop on the GPUI thread while WebView2 creates asynchronously; a window close dispatched inside that pump destroys the last window and the process exits mid-creation (or AVs, timing-dependent). Windows now uses lb-wry's build_as_child_async behind a per-key slot map (Creating{id, phase, pending_url} / Ready). Creation runs on the GPUI foreground executor; completion installs the view only if the window, panel, and exact creation generation are all still alive, else the raw webview is dropped through a panic-guarded helper. Duplicate ensures while Creating are coalesced; navigations replay from the stored URL on completion; value-returning ops answer a retryable 'preview is starting' error. A shared WebContext pins the WebView2 user-data folder under the tcode data dir instead of the exe-adjacent default. macOS keeps its proven synchronous path. The smoke harness now proves the fix: drop-during-create waits for a genuinely in-flight creation, drops the victim generation, and a new recreate-after-inflight-drop phase shows the same key reaches Ready afterwards — with the primary window retained so premature process exit is observable. Closes#149 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Tryanks · 2026-08-22T16:05:11Z

Physical Windows 11 validation complete — 3/3 PASS.

Same machine and harness that deterministically reproduced the failure (3/3 runs died at drop-during-create, silent exit 0 mid-phase). With this fix, three consecutive runs under procdump (unhandled-exception monitor, -ma -e):

phase drop-during-create ok
phase recreate-after-inflight-drop ok
phase quit ok
preview-smoke: PASS × 3

Zero crash dumps produced. Environment: Windows 11 26200, WebView2 Evergreen 151.0.4129.101.

Tryanks merged commit 24703d5 into mainAug 22, 2026
4 checks passed

Tryanks deleted the fix/149-async-webview-creation branch August 22, 2026 16:05

This was referenced Aug 23, 2026
Roadmap: near-term priorities #125
Closed
refactor(preview): extract the browser lifecycle behind an internal seam #265
Merged