Skip to content

[Bug]: preview_type reports success but text never reaches the preview input, and leaks into the user's focused T3 field #17478

Open
#17575
Open
[Bug]: preview_type reports success but text never reaches the preview input, and leaks into the user's focused T3 field#17478
#17575
Labels
bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

Description

@ycmjason
ycmjason
opened on Oct 9, 2026

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

  1. Serve a page with a single input locally, e.g. python3 -m http.server 8799 over:

    <label>Name <input id="name" aria-label="Name"></label>
<button onclick="console.log('value', document.getElementById('name').value)">Greet</button>

  2. While the user has keyboard focus in an editable field in the T3 desktop app, have an agent call:

    • preview_open { "url": "localhost:8799" } (default open: true), then
    • preview_type { "locator": "role=textbox[name='Name']", "text": "Jason" } (also tried clear: true and an aria-ref= locator from preview_snapshot)
    • preview_press { "key": "J" }, { "key": "o" }

  3. Read the input with preview_evaluate document.getElementById('name').value.

  4. Repeat with a fresh background tab: preview_open { "open": false, "reuseExistingTab": false, "url": "http://127.0.0.1:8799/" }, then preview_type { "text": "zq" } on the same input.

Expected behavior

The text is inserted into the targeted input in the preview tab, and nothing reaches the T3 UI. If text can't be delivered, the tool returns an error instead of success.

Actual behavior

  • Every preview_type / preview_press call returns success, but the page's input stays empty (preview_evaluate returns "", with document.activeElement being the input and document.hasFocus() === true).
  • In the inline tab (open: true), the typed text ("Jason", "J", "o") landed in the field the user had focused in the T3 desktop app instead.
  • In the background tab (open: false), the text also never reached the page.
  • preview_click, preview_navigate, preview_snapshot and preview_evaluate all worked normally in both tabs. The preview reported visible: false throughout, including after preview_open with open: true on the existing tab.

This looks like the keystroke leak from #3715 / #5792 again, now via preview_type, on a build that includes #11354. #10980 also describes preview_press reporting success without the key reaching the page.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261008.2833

Environment

macOS 26.6.2 (Apple Silicon), T3 Code Desktop (Nightly), provider Claude (claude-opus-5-5), local environment

Workaround

Set input values with preview_evaluate (assign .value and dispatch an input event) instead of preview_type / preview_press.

Activity

  1. juliusmarminge commented on Oct 9, 2026

    @juliusmarminge
    juliusmarminge
    on Oct 9, 2026
    Member

    Note

    Grok responding on behalf of Julius.

    Thanks for the detailed repro and the preview_evaluate workaround. From reading main at ec80933ac (not reproduced), this looks like a regression from the server-browser move rather than #11354 failing.

    How text is delivered now. Since #15328 (merged 2026-10-06), desktop tabs are no longer typed into by the desktop's own keyboard code. The server drives them with Playwright: preview_type ends in page.keyboard.insertText (ServerBrowserPage.ts:260-320), with clear: true + locator going through locator.fill (L263-L265), and preview_press is a bare page.keyboard.press (L403-L405), dispatched from ServerBrowser.ts:1922-1929. For a desktop tab, those CDP Input.* commands are relayed straight to the <webview>'s webContents.debugger (CdpRelay.ts:1-10, DesktopBrowserHost.ts:114-120). There is no webContents.focus(), focus emulation, or host-side suppression on that path. Chromium appears to route CDP key/IME input for a guest <webview> to the focused widget of the embedding window, so when the T3 UI holds focus the text can land there. That matches the leak #11354 described and fixed for the old path.

    #11354. It added PreviewKeyboard.ts (native key packets for the focused preview frame, suppressing forwarding to the desktop). #15328 deleted that file, and nothing equivalent is on main, so your build has #11354 in history but not on the code path that preview_type uses today. Open #8494 (and #3715) also target the removed PreviewKeyboard.ts / desktop IPC path, so they don't seem to cover this.

    Background / visible: false tabs. An inactive webview sits off-screen with visibility: hidden and pointer-events: none (hostedBrowserWebviewStyle.ts:66-74) and is not the focused webContents, so DOM focus inside the page (your document.activeElement check) doesn't seem to be enough for the routed input to arrive.

    Success without delivery. type only checks that the target is an editable field and takes DOM focus (L266-L315), then returns after insertText without reading the value back; press has no check at all. A read-back of the field after typing (and an error on mismatch) would turn this into a visible failure.

    Possible direction: deliver desktop-tab text inside the page (or reinstate #11354-style frame-targeted input/suppression in the relay), and verify delivery before reporting success. Related: #3715, #8494, #5792 / #11354, #10980, #15328.

  2. juliusmarminge
    added
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 9, 2026

  3. xHeaven commented on Oct 9, 2026

    @xHeaven
    xHeaven
    on Oct 9, 2026

    What happened

    The same failure occurs on 0.0.46-nightly.20261009.2886 on macOS.

    With the collaborative browser sidebar visible beside chat, preview_type sends sample email/password text into the T3 chat composer instead of the targeted website inputs. The tool returns success, but both website fields remain empty.

    The user reports that closing the browser sidebar makes filling work.

    Expected behavior: text reaches only the targeted website input, the chat composer remains unchanged, and failed delivery does not report success.

    Diagnosis

    The source at installed commit aa8c6662e212 supports the focus-routing hypothesis already discussed here:

    • ServerBrowserPage.type calls locator.fill() when a locator and clear: true are supplied. Other typing uses page.keyboard.insertText(). Neither branch verifies the resulting field value.
    • Installed bundled Playwright inspection found that filling these text controls can fall back to keyboard insertion, ultimately using CDP Input.insertText.
    • ServerBrowserContexts connects desktop pages over CDP. DesktopBrowserHost and CdpRelay forward commands to the guest debugger without special handling for text input.
    • The older desktop implementation edited inside the guest runtime to avoid hidden-guest Input.insertText problems. Its keyboard-routing comment explicitly describes CDP input following embedder focus.

    The suspected mechanism is that native/embedder focus determines input delivery despite DOM focus inside the guest. This remains a source-supported hypothesis, not an isolated Electron-level proof.

    Steps to reproduce

    1. Open T3 Code Nightly desktop on macOS.
    2. Open https://semantic-ui.com/examples/login.html in collaborative preview.
    3. Leave the browser sidebar visible beside chat.
    4. Ask the agent to fill sample credentials without submitting.
    5. Have the agent call preview_type using snapshot aria-ref locators and clear: true.
    6. Inspect both website input values and the chat composer.

    Observed: the tool reports success, the website fields remain empty, and the user sees the supplied text in the composer.

    Version

    Desktop: 0.0.46-nightly.20261009.2886, commit aa8c6662e212.

    The separately invoked npx t3 triage reports CLI version 0.0.45; that is not the affected desktop version.

    Environment

    macOS, Apple Silicon, Darwin 27.0.0. T3 Code Nightly desktop with its integrated collaborative browser. Triage CLI runtime: Node v26.8.2.

    Evidence

    • Earlier tool verification found both website inputs empty after successful preview_type calls.
    • The user observed text entering the chat composer.
    • A supplied screenshot shows chat beside the login form, with both website inputs empty. It establishes the layout and empty fields, not the input-routing mechanism.
    • Direct preview_evaluate assignment of the guest input values worked.

    No fresh sidebar-open/sidebar-closed comparison or native-focus instrumentation was performed. The sidebar workaround is user-reported. No additional input was injected during this triage follow-up.

    Suggested regression coverage: an integrated Electron test with the composer focused and browser sidebar visible, asserting that preview_type with snapshot references and clear: true updates only the guest inputs. Include sidebar-closed coverage and failed-delivery reporting.

    Related issues

    This adds evidence to #17478 rather than opening a duplicate.

    Fix applied or workaround

    No fix applied. Closing the sidebar reportedly permits filling. Direct guest value assignment through preview_evaluate worked in the investigation.

    Filed by

    Codex with GPT-6.1-Sol, via npx t3 triage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions