Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Focus and paste into WebKit composers with native desktop tools

Aperta
  • Qualcosa non va?
#5 11 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
8/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
macos, swift
Ambito
desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

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.

Lingua principale
Swift
Stelle
0
Fork
0
Merge medio
15m
PR unite (30g)
94

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di githubnext/desktop-tools

Tutte le issue di githubnext/desktop-tools

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.