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
- Resolve the exact client rectangles for characters
A through A in ALPHA using a read-only DOM Range.
- Call
tab.cua.drag(...) with a multi-point horizontal path from the first character to the last.
- 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
- Click
#textarea and verify document.activeElement.id === "textarea".
- Send
End through tab.cua.keypress(...).
- Send
Shift+ArrowLeft twice.
- 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.
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 andcontenteditable;selectionStart/selectionEndstay unchanged for a focusedtextarea.The same Browser Use commands, coordinates, and minimal page work in the connected Chrome backend.
Environment
26.803.61601(bundle build6396)26.5.2(25F84)arm6426.803.61601Minimal page
Serve the page from localhost, then use Browser Use against the IAB backend.
Reproduction 1: mouse drag
AthroughAinALPHAusing a read-only DOMRange.tab.cua.drag(...)with a multi-point horizontal path from the first character to the last.window.getSelection().toString().IAB result:
Chrome result with the same coordinates and path:
The IAB failure also reproduces on the native
contenteditableelement. Reverse-direction drag, an 11-point dense drag path, andkeys: ["SHIFT"]all produce no selection and noselectionchange.Reproduction 2: keyboard selection
#textareaand verifydocument.activeElement.id === "textarea".Endthroughtab.cua.keypress(...).Shift+ArrowLefttwice.selectionStart,selectionEnd, and the selected substring.The IAB receives the correct events on the focused textarea:
However, the default action never occurs:
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
selectionchangeis emitted for drag selection. Focus is established for the textarea, and key events include the correctShiftmodifier, 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.