›_ Codex Issues
Codex Issues / #38300

Codex Desktop IAB dispatches input events but native text selection never changes

Open 💬 0 comments Opened Aug 13, 2026 by terry90918

Description

Codex Desktop's in-app Browser (IAB) dispatches the expected mouse and keyboard events to text elements, but the browser's native text-selection default action does not occur. window.getSelection() stays empty for ordinary text and contenteditable; selectionStart / selectionEnd stay unchanged for a focused textarea.

The same Browser Use commands, coordinates, and minimal page work in the connected Chrome backend.

Environment

  • Codex Desktop: 26.803.61601 (bundle build 6396)
  • macOS: 26.5.2 (25F84)
  • Architecture: Apple Silicon / arm64
  • Bundled Browser plugin: 26.803.61601

Minimal page

<!doctype html>
<meta charset="utf-8">
<p id="plain">ALPHA BRAVO CHARLIE DELTA</p>
<div id="editable" contenteditable="true">ECHO FOXTROT GOLF HOTEL</div>
<textarea id="textarea">INDIA JULIET KILO LIMA</textarea>

Serve the page from localhost, then use Browser Use against the IAB backend.

Reproduction 1: mouse drag

  1. Resolve the exact client rectangles for characters A through A in ALPHA using a read-only DOM Range.
  2. Call tab.cua.drag(...) with a multi-point horizontal path from the first character to the last.
  3. Read window.getSelection().toString().

IAB result:

mousedown target=plain buttons=1 selection=""
mousemove target=plain buttons=1 selection=""
mousemove target=plain buttons=1 selection=""
mouseup   target=plain buttons=0 selection=""
final getSelection() = ""
selectionchange events = 0

Chrome result with the same coordinates and path:

mousedown target=plain buttons=1 selection=""
mousemove target=plain buttons=1 selection="ALP"
selectionchange selection="ALP"
mousemove target=plain buttons=1 selection="ALP"
selectionchange selection="ALPHA"
mouseup   target=plain buttons=0 selection="ALPHA"
final getSelection() = "ALPHA"

The IAB failure also reproduces on the native contenteditable element. Reverse-direction drag, an 11-point dense drag path, and keys: ["SHIFT"] all produce no selection and no selectionchange.

Reproduction 2: keyboard selection

  1. Click #textarea and verify document.activeElement.id === "textarea".
  2. Send End through tab.cua.keypress(...).
  3. Send Shift+ArrowLeft twice.
  4. Read selectionStart, selectionEnd, and the selected substring.

The IAB receives the correct events on the focused textarea:

keydown End shiftKey=false
keyup   End shiftKey=false
keydown Shift shiftKey=true
keydown ArrowLeft shiftKey=true
keyup   ArrowLeft shiftKey=true
keyup   Shift shiftKey=false

However, the default action never occurs:

IAB:    selectionStart=0 selectionEnd=0 selected=""
Chrome: selectionStart=20 selectionEnd=22 selected="MA"

Double-click selection also stays empty in IAB for both ordinary text and contenteditable, while Chrome selects the target word.

Expected behavior

CUA drag, double-click, and keyboard selection should trigger the browser's native text-selection behavior. A subsequent read of getSelection() or the form control selection range should return the selected text.

Actual behavior

IAB dispatches the input events to the correct target, but suppresses or fails to execute the browser default selection action. No selectionchange is emitted for drag selection. Focus is established for the textarea, and key events include the correct Shift modifier, but the caret/selection does not move.

Impact

This blocks workflows that require selecting visible text before applying a rich-text command, including adding native hyperlinks in Lexical/contenteditable editors. The failure was initially observed in Vocus's Lexical editor, but the localhost reproduction shows that neither Vocus nor Lexical is required.

Workaround

Use the connected Chrome backend for real mouse selection and exact selection readback. Direct DOM/selection injection is not an equivalent workaround because it can diverge from the editor's native state.

View original on GitHub ↗