Repository navigation
[Bug]: Separate preview window input fails on Windows with a WSL-hosted browser #19673
Description
Summary
Human input failed in the separate preview window, while the same local input fixture accepted physical typing and clicks when embedded in the Windows T3 window. The initial report concerned Microsoft sign-in; the follow-up narrows it to the preview view used.
The failed attempt received clicks on the heading, left the input unfocused, and received no typing events. The embedded retry received abc123 and the button click. The exact cause is not established.
Environment
Verified on 2026-10-14/15 UTC:
| Component | Value |
|---|---|
| Windows client OS | Windows 11 Business, 10.0.26200, 64-bit |
| Running T3 desktop | 0.0.46-nightly.20261014.3118 |
| WSL T3 server | 0.0.46-nightly.20261014.3118, Linux x64 |
| WSL OS/kernel | Ubuntu 24.04.5 LTS; 6.6.87.2-microsoft-standard-WSL2 |
| Browser runtime/profile | server / default |
| Browser | Linux Chrome Headless Shell 154.0.8037.92 |
| Fixture viewport | 640 × 800 CSS pixels; DPR 2 |
| Agent provider | Codex |
Versions came from the running Windows executable/OS, t3_environment_read, t3_preview_list, and the browser. The browser runs in WSL, rather than a Windows desktop webview.
Steps and expected behavior
- Connect Windows T3 Code Nightly to Ubuntu WSL.
- Open an agent-owned, server-hosted browser tab with a plain text input and button.
- Display the separate preview window, take control, click the text field, type
abc123, then click the button. - Repeat with the preview embedded in the T3 window.
Expected: both views deliver clicks to the clicked element and physical typing to the focused field.
The view-mode distinction is user-reported; tool screenshots show the page, not the enclosing T3 window. The DOM results below were independently read back.
Failed local-page attempt
The user reported that the requested interaction did not register. The subsequent capture, before any further agent input, showed:
{
"value": "",
"activeElement": "BODY",
"documentHasFocus": true,
"counts": {
"pointerdown": 2, "click": 1, "focus": 0,
"keydown": 0, "keyup": 0, "input": 0,
"paste": 0, "wheel": 0, "buttonClicks": 0
},
"recentEvents": [
{"type": "pointerdown", "target": "H1", "time": "2026-10-15T00:08:04.658Z"},
{"type": "click", "target": "H1", "time": "2026-10-15T00:08:04.739Z"},
{"type": "pointerdown", "target": "H1", "time": "2026-10-15T00:08:05.840Z"}
]
}Some pointer input arrived at the heading. The field was never focused. This does not show that every remote input packet was lost.
Embedded-view retry: passes
The user then reported working interaction when the preview remained embedded in T3. Value/counters were cleared at 00:11:03Z, and the user repeated the field/typing/button test. No agent input commands ran during this retry.
{
"value": "abc123",
"activeElement": "test-button",
"documentHasFocus": true,
"counts": {
"pointerdown": 2, "click": 2, "focus": 2,
"keydown": 6, "keyup": 6, "input": 6,
"paste": 0, "wheel": 0, "buttonClicks": 1
}
}Text events occurred at 00:12:13–00:12:15Z; the button click was at 00:12:16.850Z. Control was human, generation 5, before capture, and agent, generation 6 after release. Read-back after release confirmed these values.
Agent preview_type and preview_click also succeeded in an earlier baseline on this fixture.
Original Microsoft sign-in observation
On login.microsoftonline.com, the user twice reported ignored typing after taking control. The API had confirmed a visible human-controlled tab. Later read-back showed document focus, an active/enabled/writable email input, and value length 0. Page inspection and resizing worked; no page-console errors or failing requests were returned.
The original viewport was 1280 × 800; resizing to 640 × 600 and retaking control did not fix that attempt. Microsoft sign-in has not yet been retried in the working embedded view.
Evidence and limits
Saved locally: host/browser metadata, control observations, timestamped counters, screenshots, fixture source, and redacted preview-related traces from both hosts. Essential observations are copied above; the ZIP is not a GitHub attachment. Credentials, tenant/OAuth URLs and client project files are excluded.
The traces do not establish receipt of individual human-stream input packets. Client-side click coordinates were not recorded. Incorrect coordinate translation/focus in the separate window is a hypothesis, not a proved cause. An ordinary public search box has not been tested.
Impact and workaround
The affected view blocked human sign-in and handoff. The embedded preview passed the plain-input test and is a verified workaround for that fixture; authenticated-site behavior is not yet established.
Related reports
- [Bug]: iOS remote preview — "You have control" but taps never reach the tab; streams stuck on "Connecting to browser…" after refresh / for other tabs #19420: human input/remote preview failure on iOS to Mac; this adds a Windows-to-WSL view comparison.
- [Bug]: preview_type reports success but text never reaches the preview input, and leaks into the user's focused T3 field #17478: agent typing misrouted in desktop-hosted tabs; agent input worked in our WSL-hosted fixture.
Existing reports were searched before filing. The original broader title/body have been replaced with this follow-up evidence.
Activity
juliusmarminge commentedon Oct 14, 2026
Note
Grok responding on behalf of Julius.
We need one more result before treating this as a T3 bug: the manual typing test on your plain local input page in the same WSL-hosted tab setup.
Right now the failure has only been seen on
login.microsoftonline.com, which does a lot of redirects and script-driven focus handling, so we can't yet tell a T3 input-forwarding problem apart from site behavior. Please reply with:abc123by hand into your local fixture works after taking control, and the keydown/input counts it shows.If the fixture also drops human keys, this likely belongs with #19420 (human control input not reaching remote tabs). Open PR #16691 (input stalling behind a slow navigation in server browser tabs) may also be relevant to the redirect case.
[-][Bug]: Microsoft sign-in ignores human typing in Windows to WSL streamed preview[/-][+][Bug]: Separate preview window input fails on Windows with a WSL-hosted browser[/+]kendonB commentedon Oct 15, 2026
The manual fixture test is now completed, and the result depends on the preview view used.
Embedded in the Windows T3 window: passes. After clearing the fixture's value/counters at
2026-10-15T00:11:03Z, the user took control, clicked the field, physically typedabc123, and clicked the button. No agent input commands were run during this trial. After the user released control, page read-back showed:{ "value": "abc123", "activeElement": "test-button", "documentHasFocus": true, "counts": { "pointerdown": 2, "click": 2, "focus": 2, "keydown": 6, "keyup": 6, "input": 6, "paste": 0, "wheel": 0, "buttonClicks": 1 } }The text events were timestamped
00:12:13–00:12:15Z; the button click was at00:12:16.850Z.preview_statusshowedowner: human, generation 5, before the capture attempt, thenowner: agent, generation 6 after release.Earlier failed local-fixture attempt: the user said that the requested field/typing/button interactions did not register, then said interaction worked when it was embedded in the T3 window. The earlier capture showed an empty field,
activeElement: BODY, zero focus/keydown/keyup/input/button-click events, and:{ "pointerdown": 2, "click": 1, "recentEvents": [ {"type": "pointerdown", "target": "H1", "time": "2026-10-15T00:08:04.658Z"}, {"type": "click", "target": "H1", "time": "2026-10-15T00:08:04.739Z"}, {"type": "pointerdown", "target": "H1", "time": "2026-10-15T00:08:05.840Z"} ] }So some pointer input reached the page in that attempt, but it reached the heading, and the text field was never focused. This is more specific than "all input is dropped." The view-mode distinction is user-reported: our tool screenshots capture the web page, not the surrounding T3 window. Misplaced click coordinates/focus in the separate preview window is a hypothesis; client-side pointer coordinates were not recorded, so the cause is not proved.
Same tab, server-hosted browser, Windows/WSL versions
0.0.46-nightly.20261014.3118,640 × 800CSS viewport, browser DPR 2. The successful result is for the plain fixture; Microsoft sign-in has not yet been retried in the embedded view. I have updated the issue title/body to reflect this narrower finding.juliusmarminge commentedon Nov 12, 2026
Thanks for writing this up. It asks for new behaviour rather than reporting a defect, so it does not belong in the bug tracker and I'm closing it as not planned here. Feature ideas are discussed in Discussions: please post it there.