Focus and paste into WebKit composers with native desktop tools
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
- Issue-Typ
- Bug
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- typescript
- Bereich
- tooling
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Point click, window in the background.
desktop_clickat (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. desktop_focus, then the same point click. Focus reportedconfirmed_change, but the click was refused again with the same occlusion error. On 56752, afterdesktop_activatereported the app active, a point click at (820, 804) on the composer was also refused as occluded.- Element click on the textarea.
desktop_clickon the AXTextArea "Message" was accepted (accessibility_action,dispatched_unverified). The next inspect still reported the AXWindow as the focused element, and the textarea hadisFocused=false. This was seen on both PIDs, the second time right afterdesktop_activate. desktop_selectwithcursor_beforeon the textarea returnedconfirmed_no_change, and focus stayed on the AXWindow.desktop_typewriting "x" returned "The accessibility value write was accepted, but its requested result could not be verified." Nothing appeared in the composer.- Background Cmd+V. Setting
AXFocused=trueon the textarea outside the tools made the next inspect report the AXTextArea as focused.desktop_keyCmd+V, delivered as backgroundwindow_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. desktop_focusrefused. Once, while the user was working in another app,desktop_focuswas 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_clickon 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_keydelivers 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.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 1
- Forks
- 0
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Kein Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus githubnext/ace2
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 94/100
githubnext/ace2#487 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
githubnext/ace2#486 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 67/100
githubnext/ace2#459 ·
-
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
githubnext/ace2#437 ·
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 35/100
githubnext/ace2#442 ·
Alle Issues in githubnext/ace2
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
OpenPetsHQ/openpets#273 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
fritzprix/libr-agent#2161 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 83/100
blackboardsh/electrobun#581 ·
-
backlog-skill effort:xs frontend infra ready-for-agent
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
LucasSantana-Dev/Lucky#2862 ·
Maintainer antworten meist innerhalb von 1 Tag