Focus and paste into WebKit composers with native desktop tools

This is a macOS accessibility and input-delivery bug, and the payload names no repository files. Start with the desktop_click, desktop_focus and desktop_key paths that the failing steps exercise, and reproduce step 1 against an Electrobun WKWebView window. Done means a point click on the Message composer is not refused as occluded, and an element or point click gives the contenteditable keyboard focus. Background Cmd+V is still open and is not claimed fixed.

While validating PR githubnext/ace2#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. githubnext/ace2#103 keeps the Automation-prompt and agent-guidance problem.

October 5 progress: githubnext/ace2#120 fixes verified editable element focus; githubnext/ace2#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. githubnext/ace2#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 githubnext/ace2#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. githubnext/ace2#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 githubnext/ace2#103. Sub-issue of githubnext/ace2#8 (slices 3–5, tracked under githubnext/ace2#5). Related: githubnext/ace2#65, githubnext/desktop-tools#2, githubnext/desktop-tools#4. Found during githubnext/ace2#91 / PR githubnext/ace2#104.