Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

WebKit: background Command-V, and Safari page fields missing from Accessibility

Offen
  • Stimmt etwas nicht?
#5 11 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
8/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
macos, swift
Bereich
desktop

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement

Focus, clicking, desktop_type and desktop_insert now work in WebKit composers, including Ace's (#82, #68, #88, and ace2 #120, #131 and #141). Two things are still unknown.

1. Background Command-V into a web app that isn't frontmost. A background desktop_key Command-V into a focused WKWebView composer didn't land. Text has a working route through desktop_insert. An image or file paste into the composer doesn't. Before any patch, answer these with Safari in the background and a textarea focused:

  • Is Edit › Paste AXEnabled, both with and without the host's background key-window preparation?
  • Does an Accessibility press of Edit › Paste paste into the textarea?
  • Must the textarea have AXFocused first?

The answers decide between a menu-press route, a foreground fallback, and a clear refusal.

2. Safari page fields missing from the Accessibility tree. In the Oct 15 study (D6), a local Safari page's <input>, <textarea> and contenteditable weren't in desktop_inspect, so the agent had to click coordinates. Chrome and Electron are handled by #107. For Safari, the cause isn't known: WebKit might load its accessibility lazily, or the 200-element inspect cap might cut the tree short. Reproduce it, then fix it or document the workaround.

Vorherrschende Sprache
Swift
Sterne
0
Forks
0
Ø Merge
19 Min.
Gemergte PRs (30 T.)
107

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus githubnext/desktop-tools

Alle Issues in githubnext/desktop-tools

Ähnliche Issues

Weitere Issues zu Swift

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.