Focus and paste into WebKit composers with native desktop tools

Start from the refusal text "Point ... is occluded for the pinned target window" to locate the accessibility hit-testing check behind desktop_click, then the focus path used by desktop_focus and element clicks targeting the AXTextArea "Message" (a ProseMirror contenteditable in a WKWebView). Use the numbered repro steps and the target PIDs/windows as your test matrix. The still-unclaimed cases are background desktop_key Cmd+V delivery and direct AX value replacement; done means a point or element click on an Electrobun web control yields verified keyboard focus without occlusion refusals, and Cmd+V either pastes or explains why it cannot.

While validating PR #104 (#91) in Ace Canary 0.0.11, Ace's desktop tools couldn't place focus in the Ace-dev (Electrobun/WKWebView) composer or paste into it. This issue records the tested failures only. #103 keeps the Automation-prompt and agent-guidance problem.

October 5 progress: #120 fixes verified editable element focus; #131 fixes the reproduced external WebKit button’s false coordinate occlusion. A combined signed-main check also passed activation → element focus → one dedicated literal insertion in Ace’s actual composer, with exact Unicode/multiline draft/caret, unchanged chat history, and clipboard restoration. #141 additionally fixes actual-Ace editable coordinate focus: one normalized point click gave the Message field verified keyboard focus, left the existing draft unchanged, and preserved the empty history across worker exit/reopen. Background desktop_key Cmd+V, direct AX value replacement, and the other remaining cases below are not claimed fixed.

Targets were Ace-dev builds from the #104 branch:

• PID 50933, window 4742, 1100x760 at (160,120)
• PID 56752, window 4821, same bounds

The Message composer is a ProseMirror contenteditable, exposed as an AXTextArea "Message".

Tested steps and results

1. Point click, window in the background. desktop_click at (0.5, 0.32), on the composer, was refused: "Point (710, 363) is occluded for the pinned target window 4742: accessibility hit-testing resolved an element in a different window of the same app." A CGWindowList check at that point showed Ace-dev window 4742 as the topmost layer-0 window. Electrobun also creates invisible strip windows (2560x30 at y=0 and 1512x33 at y=1440); none of them contains that point.
2. desktop_focus, then the same point click. Focus reported confirmed_change, but the click was refused again with the same occlusion error. On 56752, after desktop_activate reported the app active, a point click at (820, 804) on the composer was also refused as occluded.
3. Element click on the textarea. desktop_click on the AXTextArea "Message" was accepted (accessibility_action, dispatched_unverified). The next inspect still reported the AXWindow as the focused element, and the textarea had isFocused=false. This was seen on both PIDs, the second time right after desktop_activate.
4. desktop_select with cursor_before on the textarea returned confirmed_no_change, and focus stayed on the AXWindow.
5. desktop_type writing "x" returned "The accessibility value write was accepted, but its requested result could not be verified." Nothing appeared in the composer.
6. Background Cmd+V. Setting AXFocused=true on the textarea outside the tools made the next inspect report the AXTextArea as focused. desktop_key Cmd+V, delivered as background window_targeted_events, then changed nothing while Ace-dev wasn't frontmost. A plain-text clipboard didn't paste either, so this isn't specific to images.
7. desktop_focus refused. Once, while the user was working in another app, desktop_focus was refused with "Timeout while waiting for condition", operation_unsupported.

What worked: with Ace-dev frontmost after desktop_activate, setting AXFocused on the textarea and pressing the app's Edit > Paste menu item through Accessibility pasted reliably. Native desktop_key Cmd+V wasn't retried in the frontmost state because steps 2–4 never produced a focused control.

Not tested (corrected assumption)

In Finder, desktop_key Cmd+C was refused: "The snapshot has no exact focused control. Click a control, then inspect the window again." The agent didn't follow that hint (click a file row, inspect again) before switching to osascript. Whether the native tools can copy from Finder's file list is therefore unverified. #103 originally listed it as a gap; the review comment there corrected that.

Expected

• desktop_click on a visible web control in Electrobun windows isn't refused as occluded.
• An element or point click on a WKWebView contenteditable gives it keyboard focus.
• desktop_key delivers Cmd+V to that control, or explains why it can't.

This issue covers capability bugs; prompt guidance is in #103. Sub-issue of #8 (slices 3–5, tracked under #5). Related: #65, #68, #73. Found during #91 / PR #104.