Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#13 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #51 di @iamnbutler — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
macos, swift
Ambito
desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Swift
Stelle
0
Fork
0
Merge medio
19m
PR unite (30g)
107

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di githubnext/desktop-tools

Tutte le issue di githubnext/desktop-tools

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.