[Bug]: preview_press does not reliably target the preview page
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 23k
- Forks
- 5.9k
- Avg merge
- 11h 14m
- Merged PRs (30d)
- 357
Description
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
-
Start T3 Code Desktop.
-
Open a Codex-backed thread with the T3 preview MCP tools available.
-
Open any page in the browser preview.
-
Install a page-level keydown listener:
(() => { window.__t3KeyEvents = []; window.addEventListener( "keydown", (event) => { window.__t3KeyEvents.push({ key: event.key, code: event.code, target: event.target && event.target.tagName, active: document.activeElement && document.activeElement.tagName, time: Date.now() }); }, true ); return { active: document.activeElement && document.activeElement.tagName, events: window.__t3KeyEvents }; })() -
Confirm
document.activeElementisBODY. -
Call
preview_pressbefore clicking inside the page:{ "key": "b" } -
Read
window.__t3KeyEvents. -
Click inside the preview page body with
preview_click. -
Clear the log and call
preview_pressagain:{ "key": "c" } -
Clear the log and call
preview_presswithEscapethree times. -
In a separate hidden or degraded tab, call
preview_presswithTab, then call a simplepreview_evaluate.
Expected behavior
preview_press should target the selected preview page consistently when a tabId is provided.
If the preview page is not focusable or the tab cannot receive keyboard events, the tool should return a clear failure. It should not return null while no key event reaches the page.
Keyboard events should not go to the T3 host prompt when the agent is trying to target the preview page.
Actual behavior
Before a real click inside the page, preview_press("b") returned null, but the page captured no key event:
{
"active": "BODY",
"events": []
}
After clicking the page body, preview_press("c") returned null and the page captured the event:
{
"active": "BODY",
"events": [
{
"active": "BODY",
"code": "KeyC",
"key": "c",
"target": "BODY"
}
]
}
After focus was established, three Escape presses all returned null, but only two page-side keydown events were captured.
In an earlier run, a printable key was not captured by the page and the human operator observed that the character appeared in the T3 prompt input instead.
On a previously degraded invisible tab, preview_press("Tab") timed out after 15 seconds, and a simple preview_evaluate immediately afterward also timed out.
Impact
Major degradation or frequent failure
Version or commit
T3 Code desktop 0.0.28-1 via t3code-bin AUR package.
Environment
Arch Linux x86_64, kernel 7.0.13-arch1-1, T3 Code desktop AppImage package via t3code-bin, Codex provider.
Logs or stack traces
Representative timeout after pressing in a degraded invisible tab:
PreviewAutomationTimeoutError: Preview automation press timed out after 15000ms.
PreviewAutomationTimeoutError: Preview automation evaluate timed out after 15000ms.
Screenshots, recordings, or supporting files
No screenshot included. Page-side key event logs are the relevant evidence. A recording could help demonstrate the host-prompt mutation, but the agent cannot inspect that host input directly.
Workaround
Before using preview_press, click inside the preview page and verify delivery with a page-side listener or an observable page effect. Avoid keyboard workflows in hidden or already-degraded tabs. Prefer preview_type for text input and preview_evaluate for state changes that are not specifically testing keyboard behavior.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the preview_press entry point under apps/desktop and reproduce the documented key-event and degraded-tab cases. Compare delivery when tabId is supplied, after a page click, and in hidden tabs. Done means keys consistently reach the selected preview page or the tool returns a clear failure instead of null or an unexplained timeout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- desktop
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100