Summary
Clipboard paste into X Draft.js compose is unreliable when relying on DISPLAY-scoped xclip plus Ctrl+V / Shift+Insert (no-op if Chrome is unfocused or on another DISPLAY). Product should standardize on one in-browser insertion path that Draft.js accepts consistently.
Repro
- Context: Compose focused or not; optional OS clipboard set via
xclip on a given DISPLAY.
- Steps:
- Put URL/body on clipboard; send Ctrl+V or Shift+Insert via automation while Chrome may not own focus.
- Compare with CDP
insert_text (Input.insertText) and with document.execCommand('insertText') via draft_fast_path.
- Observed: clipboard shortcuts often no-op; CDP/
execCommand behave differently regarding doubling and caret (see P0 append/caret issues).
Code pointers (verified against /workspace/FSB)
extension/background.js — cdpInsertText uses chrome.debugger + Input.insertText (~L19206–19209, ~L20093); alternate document.execCommand('insertText') fallback elsewhere (~L15258–15262).
extension/content/actions.js — draft_fast_path execCommand('insertText') then textContent fallback (~L2987–2995).
extension/ai/tool-definitions.js — insert_text _cdpVerb: 'cdpInsertText'.
Proposed fix
Declare CDP Input.insertText (via insert_text / cdpInsertText) as the supported compose insertion path; document that OS clipboard paste is best-effort only. Align draft_fast_path to the same semantics (single insert, clear_first honored) so callers are not forced through xclip. Root cause: multiple competing insert mechanisms with different focus/selection requirements.
Acceptance / regression
- Documented primary path: focus compose →
insert_text (CDP) with clear_first false for append.
- Clipboard shortcut path either removed from recommended flow or gated on verified focus.
- Compose insert succeeds without DISPLAY clipboard.
Owner
extension
Priority: P0 · Owner: extension
Summary
Clipboard paste into X Draft.js compose is unreliable when relying on DISPLAY-scoped
xclipplus Ctrl+V / Shift+Insert (no-op if Chrome is unfocused or on another DISPLAY). Product should standardize on one in-browser insertion path that Draft.js accepts consistently.Repro
xclipon a given DISPLAY.insert_text(Input.insertText) and withdocument.execCommand('insertText')via draft_fast_path.execCommandbehave differently regarding doubling and caret (see P0 append/caret issues).Code pointers (verified against /workspace/FSB)
extension/background.js—cdpInsertTextuseschrome.debugger+Input.insertText(~L19206–19209, ~L20093); alternatedocument.execCommand('insertText')fallback elsewhere (~L15258–15262).extension/content/actions.js— draft_fast_pathexecCommand('insertText')then textContent fallback (~L2987–2995).extension/ai/tool-definitions.js—insert_text_cdpVerb: 'cdpInsertText'.Proposed fix
Declare CDP
Input.insertText(viainsert_text/cdpInsertText) as the supported compose insertion path; document that OS clipboard paste is best-effort only. Align draft_fast_path to the same semantics (single insert, clear_first honored) so callers are not forced through xclip. Root cause: multiple competing insert mechanisms with different focus/selection requirements.Acceptance / regression
insert_text(CDP) with clear_first false for append.Owner
extension
Priority: P0 · Owner: extension