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

Secure Keyboard Entry refusal should name the app/window that enabled it

Ouverte
  • Quelque chose ne va pas ?
#176 0 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é
3/5
Temps estimé
1-2 jours
Accessibilité débutants
67/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
macos, swift
Domaine
accessibility, desktop

Piste de recherche

Start from the typing route that refuses input when Secure Keyboard Entry is active, then check how desktop_apps reports session.secure_keyboard_entry and how focus information is exposed. Include the focused app identity in the refusal so the user can identify the blocking dialog; done when the refusal names the app holding focus or provides its bundle ID.

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

Description

What happened

Typing into an ordinary web form field in Safari was refused:

desktop_insert → refused
"Secure keyboard entry is on, as for a password field or a terminal's
 Secure Keyboard Entry, so typed text can't be delivered. Nothing was typed."
hint: "Use a field that isn't secure, or turn off Secure Keyboard Entry in the app."

There was no secure field anywhere near the target. The actual cause was a
com.apple.NetAuthAgent SMB password dialog open behind the Safari window,
holding focus on an AXSecureTextField. macOS enables secure input globally
while that field has focus, so every synthesized keystroke in every app is
blocked.

Why the current hint doesn't help

"turn off Secure Keyboard Entry in the app" is ambiguous — which app? The
agent is pointed at its own target window, which is not the cause. I only
found the real cause by noticing focus.bundle_id had changed to
com.apple.NetAuthAgent in an unrelated desktop_apps call, then inspecting
that window.

Also note the fix is something the agent cannot do: system password prompts
are (correctly) refused to agents, so the only resolution is asking the user
to dismiss a specific dialog — which requires naming it.

Suggestion

desktop_apps already reports session.secure_keyboard_entry. When a typing
route is refused for this reason, include the app that currently holds focus
in the refusal, e.g.:

"Secure keyboard entry is on. com.apple.NetAuthAgent ("Enter your name and
 password for the server …") holds focus on a secure field. Ask the user to
 dismiss or complete it; agents cannot answer system password prompts."

Even just focused_bundle_id in the error payload would be enough to let the
agent inspect and describe it.

Environment

Desktop Tools 0.16.1 (app + MCP), macOS 27, Safari 27

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.