O fix do qual eu mesmo me convenci a desistir

Construí um harness de WebDriver para o Greenhouse um tempo atrás para um agente conseguir clicar pelo app de verdade durante a verificação, IPC real, SQLite real, sem mocks. Funciona bem. Também tem um efeito colateral irritante: toda vez que uma sessão abre, a janela do app pula para a frente da tela e rouba o foco do teclado. Se eu estiver digitando qualquer outra coisa naquele exato momento, essas teclas vão parar na janela errada.

Coloquei um agente para consertar isso, e a primeira passada de pesquisa dele se convenceu a nem tentar. A configuração de janela do Tauri tem um campo focus, mas essa é uma limitação conhecida e sem solução na biblioteca de janelas sobre a qual o Tauri é construído: definir como false não impede de forma confiável que o macOS ative o app. Certo, beco sem saída, esperado. A conclusão a partir daí foi que a única opção restante era ir além da API suportada do Tauri e mexer direto em chamadas Cocoa cruas, o que pareceu arriscado demais para recomendar. O que voltou para mim foi um relatório inteiro de “não construa isso” com esse raciocínio, mais um prêmio de consolação de me avisar antes de uma sessão roubar o foco.

Minha resposta foi direta: essa é uma solução ruim, ela anula o propósito da automação. “Me avisar antes de eu ser interrompido” não é um fix, é só agendar a interrupção. Foi essa contestação que forçou uma segunda olhada, em vez de uma defesa da primeira resposta.

A segunda passada encontrou a primeira errada nos dois pontos. tauri::App::set_activation_policy é uma API real, já lançada do Tauri, não algum workaround arriscado de FFI. Ela só está documentada no tipo errado (App, não o mais usado AppHandle), o que provavelmente é a razão de a primeira passada ter deixado passar. E a preocupação de “risco para a automação” evaporou depois de checar de verdade como o plugin de WebDriver comanda o app: tudo acontece avaliando JavaScript dentro da webview e passando resultados de volta por IPC. Nada disso toca cliques ou teclas reais no nível do sistema operacional. Um app que não pega o Dock nem se auto-ativa não tem como interferir nisso, porque esse mecanismo nunca esteve no caminho para começar.

O fix acabou sendo uma linha, atrás da mesma flag exclusiva de debug que já liga o servidor de automação. Também não confiei só no raciocínio: a verificação registrou qual app estava em primeiro plano antes de abrir uma sessão de WebDriver, abriu uma, checou de novo logo depois (sem mudança), e então rodou o script e2e completo do fluxo de captura contra o mesmo build para confirmar que a automação continuava funcionando exatamente como antes.

A lição não é realmente sobre a activation policy do Tauri. É que a primeira conclusão de “isso não vale a pena construir” foi montada sobre duas suposições nunca verificadas, empilhadas uma sobre a outra: não existe uma API de primeira classe, e construir uma seria arriscado, e as duas estavam erradas, mas soavam razoáveis o bastante para a investigação parar por ali. Rejeitar a conclusão de saída, em vez de discutir os detalhes do raciocínio, foi o que de fato reabriu a investigação.