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

Send keys to windows whose focus isn't a text field

Fermée
  • Quelque chose ne va pas ?
#13 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

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

Une pull request liée a déjà été fusionnée.

  • #51 par @iamnbutler — fusionnée

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
macos, swift
Domaine
desktop

Piste de recherche

Start in native/sources/client/actions.swift, where key and insert are refused when the snapshot has no focusedElement, then read focusedTextElement in BackgroundInputDriver.swift to see why only text receivers are accepted. Choosing between the two options is a design decision to settle with maintainers first. Done means keys reach a non-text focused receiver or the refusal names the real requirement and points to desktop_menu, with the exact process, window and focus checks kept.

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

Description

Found in the Ace desktop tools study (githubnext/ace#427), scenario D2 on Canary 0.0.46+dd15840.

Observed: desktop_key Escape to a Finder window, with a file row selected, was refused twice: "The snapshot has no exact focused control. Click a control, then inspect the window again." The agent clicked a row and tried again, and it was refused again.

Cause: native/sources/client/actions.swift refuses key and insert when the snapshot has no focusedElement. Peekaboo's background input driver only resolves a focused text element as the receiver (focusedTextElement in BackgroundInputDriver.swift). So keys only work while a text field has focus. Escape, arrow keys, Return, Space (Quick Look) and Cmd shortcuts in lists, outlines, canvases and the Finder can't be sent. The hint suggests a click that can't help.

Options:

  • Admit a non-text focused receiver (a list, outline, table or web area) with the same exact process, window and focus checks, using background delivery when the app accepts it.
  • Or expose foreground key delivery for an exact window that has been activated, with the outcome left unknown when focus can't be read back. This is the --foreground gap from #11.

Short term, the refusal should say that keys need a focused text field, and point to desktop_menu when the command is in a menu.

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

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.