Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#5 11 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
8/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
macos, swift
Domínio
desktop

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Swift
Estrelas
0
Forks
0
Merge médio
19min
PRs com merge (30d)
107

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de githubnext/desktop-tools

Todas as issues de githubnext/desktop-tools

Issues semelhantes

Mais issues de Swift

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.