Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#5 11 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
8/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
macos, swift
Domaine
desktop

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

Focus, clicking, desktop_type and desktop_insert now work in WebKit composers, including Ace's (#82, githubnext/desktop-tools#68, githubnext/desktop-tools#88, and ace2 githubnext/desktop-tools#120, githubnext/desktop-tools#131 and githubnext/desktop-tools#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 githubnext/desktop-tools#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.

Langage dominant
Swift
Étoiles
0
Forks
0
Merge moyen
39 min
PR mergées (30 j)
144

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de githubnext/desktop-tools

Toutes les issues de githubnext/desktop-tools

Issues similaires

Plus d'issues Swift

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.