Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Focus and paste into WebKit composers with native desktop tools

Open
  • Is something wrong?
#106 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
tooling

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
TypeScript
Stars
1
Forks
0
No merged PRs in 30d

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from githubnext/ace2

All issues in githubnext/ace2

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.