[Bug]: Browser automation steals composer focus across threads #5792

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

Same-thread case:

1. Open a thread in T3 Code Desktop.
2. Open its browser preview.
3. While the agent is using the preview, focus the composer and begin typing.
4. Have the agent call preview_press, such as pressing Tab.
5. Observe the composer focus.

Cross-thread case:

1. Let the agent continue browser automation in thread A.
2. Switch to thread B.
3. Focus thread B’s composer and begin typing.
4. When thread A calls preview_press, observe thread B’s composer focus.

Expected behavior

Browser automation should not interrupt typing in the composer. This should
remain true whether the automation belongs to the visible thread or a background
thread.

Actual behavior

When the agent calls preview_press, the composer loses focus and typing stops
until it is focused again. Automation from a background thread can steal focus
from the composer in the currently visible thread.

The desktop press implementation focuses the preview guest WebContents and
later restores the outer renderer, but it does not restore the renderer’s active
DOM element. Preview automation is hosted per environment rather than per
visible thread, which explains the cross-thread behavior.

Related but not duplicate to #3715: that issue concerns unreliable delivery of
agent key presses to the preview. This issue concerns the resulting loss of
human composer focus, including across threads.

Impact

Major degradation or frequent failure

Version or commit

main @ ba9c9ae

Environment

T3 Code Desktop OS: Arch Linux Provider: Codex

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Click the composer again after browser automation takes focus. Avoid
preview_press while composing when possible.