Um agente de IA deve tratar um diálogo modal como uma mudança de estado da tarefa. Antes de clicar novamente na página, precisa identificar o bloqueio, ler o que ele pede e decidir se tem autorização para responder. Fechar uma janela, confirmar uma exclusão e aceitar um aviso de sessão expirada são decisões diferentes, mesmo quando os botões ocupam o mesmo lugar.
A primeira distinção é técnica: alertas nativos de JavaScript são controlados pelo navegador; diálogos construídos no conteúdo da página fazem parte do DOM, a estrutura de elementos do site. Eles exigem mecanismos diferentes de automação. Reconhecer essa diferença evita tentativas repetidas de clicar em um botão que está atrás do bloqueio ou procurar no HTML um alerta que não pertence a ele.
Resumo rápido
- Identifique se o bloqueio é um diálogo nativo ou um componente da página.
- Leia mensagem, título, opções e efeito esperado antes de responder.
- Uma confirmação exibida pelo sistema não amplia a autorização do agente.
- Após resolver o diálogo, observe novamente a página e o registro aberto.
- Teste cancelamento, bloqueios inesperados e resultado incerto.
O que um modal muda na execução do agente
Uma caixa central com fundo escurecido costuma indicar que a aplicação espera uma resposta antes de continuar. Para o agente, isso significa suspender a sequência de cliques planejada. O próximo passo deve ser definido pelo estado observado, e não pelo roteiro anterior à abertura do diálogo.
Imagine que o agente preparou um cadastro e clicou em “Salvar”. A aplicação abre “Já existe cliente com este documento. Deseja atualizar o cadastro existente?”. A tarefa deixou de ser apenas criar um registro. Agora existe uma decisão sobre sobrescrever dados. A resposta não pode ser deduzida do objetivo geral “cadastre o cliente”.
Também é possível que uma mensagem de erro apareça em uma faixa no topo, sem impedir interação. Ela merece leitura, mas não deve ser classificada automaticamente como modal. Uma nova janela do navegador, um seletor de arquivos do sistema e uma solicitação de permissão também são superfícies distintas. O procedimento deve nomear o que realmente foi encontrado.
O padrão de diálogo modal da W3C descreve comportamento esperado de foco e navegação por teclado. Ele ajuda a equipe a reconhecer e testar componentes acessíveis. Uma interface real pode implementar esse padrão de forma incompleta; o agente precisa observar o funcionamento, além dos rótulos declarados.
Essa observação deve entrar na documentação do processo executado pelo agente. Liste diálogos previstos, resposta permitida e condição que exige revisão humana. Uma instrução como “resolva os pop-ups” deixa decisões relevantes sem critério.
Separe diálogos nativos de componentes do DOM
A documentação de diálogos do Playwright diferencia o tratamento de alert, confirm, prompt e beforeunload. Esses mecanismos nativos não devem ser tratados como botões HTML. Quando houver um manipulador de evento de diálogo, ele precisa resolver o evento com aceitação ou dispensa conforme o caso; apenas registrar a mensagem pode deixar a ação aguardando.
Já uma caixa implementada com HTML deve ser localizada na página. O elemento <dialog> é uma possibilidade, mas bibliotecas também constroem componentes com outros elementos e atributos de acessibilidade. Conforme o padrão HTML, abrir um diálogo de forma modal difere de apenas exibi-lo. Portanto, encontrar a tag não basta para deduzir todo o comportamento da interface.
| Superfície | Como reconhecer | Como tratar |
|---|---|---|
| Alerta nativo | Evento de diálogo da ferramenta | Ler tipo e mensagem antes da resposta configurada |
| Confirmação nativa | Evento com alternativa de aceitar ou dispensar | Aplicar regra específica para aquela operação |
| Modal no DOM | Conteúdo e controles localizáveis na página | Restringir a busca ao diálogo identificado |
| Aviso não modal | Mensagem sem bloqueio obrigatório do restante | Interpretar o resultado e decidir o próximo passo |
| Janela externa | Outra superfície ou recurso do navegador | Usar o mecanismo próprio da ferramenta |
Se a ferramenta não expõe informação suficiente para distinguir as superfícies, registre a limitação e interrompa a etapa dependente. Clicar por tentativa para descobrir o efeito não é um método adequado em um sistema com dados reais.
Defina uma política de resposta pelo efeito da ação
Comece separando reconhecimento de autorização. O modelo pode interpretar que “Remover definitivamente” significa excluir um item. Isso não o autoriza a excluir. A decisão precisa consultar o escopo da tarefa, a identidade do registro e as regras estabelecidas pela empresa.
Uma política prática associa cada diálogo previsto a uma condição. “Descartar alterações” só pode ser respondido quando o fluxo permite perder aquele rascunho e a identidade do formulário foi conferida. “Enviar proposta” exige que conteúdo, destinatário e autorização de envio estejam validados. “Sua sessão expirou” exige recuperação de sessão antes de retomar o registro.
Evite políticas universais como aceitar todos os diálogos ou sempre pressionar Escape. A primeira pode aprovar operações não autorizadas. A segunda pode descartar trabalho ou simplesmente não funcionar em um componente específico. Até cancelar pode produzir efeito, dependendo de como a aplicação foi implementada.
Para diálogos inesperados, a recomendação operacional é suspender ações com efeito externo e apresentar o texto relevante ao responsável. Não é preciso transferir todo o histórico da navegação. Informe qual tarefa estava em curso, qual registro estava selecionado e qual decisão nova apareceu, retirando dados pessoais desnecessários.
As regras devem acompanhar as permissões do agente. Um agente autorizado a preparar rascunhos pode preencher um formulário, mas precisa parar diante de um diálogo que efetiva o envio. A aplicação pedir confirmação não substitui a autorização da pessoa que delegou o trabalho.
Implemente o fluxo com observação e confirmação
Para um diálogo nativo esperado, configure o tratamento antes da ação que o abre. Registre tipo e mensagem suficientes para conferir a expectativa. Se o texto ou a operação diferir do previsto, não aplique silenciosamente a resposta usada no caminho feliz. O tratamento de exceção deve deixar claro se a operação foi cancelada, permaneceu pendente ou exige avaliação.
Para um modal no DOM, localize o contêiner pelo papel e nome acessível quando disponíveis. Depois procure o botão dentro desse contêiner. Isso evita confundir o “Confirmar” do diálogo com outro botão de mesmo nome na tela. Em aplicações internas, atributos estáveis podem complementar essa identificação.
O guia de verificações de ação do Playwright explica condições verificadas antes de operações, como visibilidade, estabilidade e recebimento de eventos em um clique. Se uma camada cobre o botão, insistir com uma opção que força a ação pode contornar uma proteção útil da automação. Primeiro descubra por que o alvo não está disponível.
Depois da resposta, espere um sinal correspondente ao próximo estado. Pode ser o desaparecimento do diálogo seguido da visualização do registro atualizado. Se houver mensagem de validação dentro do próprio modal, a operação pode não ter concluído. O botão ter sido acionado não comprova que o sistema aceitou os dados.
Agentes visuais precisam de uma nova observação após a mudança. As coordenadas anteriores deixam de ser uma referência confiável quando o modal fecha ou o conteúdo se reorganiza. Antes de prosseguir, confira também se a página continua no cliente e na organização esperados.
Por fim, diferencie falha de confirmação de falha da operação. Se a ferramenta perde a conexão logo depois de aceitar “Enviar”, o resultado fica incerto. Consulte o histórico ou o estado do registro antes de repetir. Reabrir o mesmo diálogo e confirmar outra vez pode duplicar uma ação já processada.
Exemplo: assistência técnica em Curitiba
Considere uma assistência técnica fictícia em Curitiba. O agente prepara o orçamento de reparo de uma lavadora e deve deixá-lo em rascunho para revisão da atendente. Durante o preenchimento, aparece um modal: “Cliente já cadastrado. Usar dados existentes?”. A equipe definiu que o agente pode consultar o cadastro, mas não sobrescrever endereço nem telefone sem conferência.
O agente identifica um componente dentro da página e lê o documento parcial e o identificador interno apresentados. Em vez de clicar automaticamente no botão destacado, compara o cadastro com a ordem de serviço. Quando a relação é inequívoca, seleciona o cliente existente sem editar seus dados. Se houver divergência, suspende o preenchimento e informa a atendente.
Ao terminar os itens, o agente clica em “Salvar rascunho”. Um defeito da aplicação poderia abrir uma confirmação com “Enviar orçamento ao cliente”. Esse texto não corresponde à operação prevista. O agente deve interromper a sequência e evitar confirmar o envio. A cor do botão e o fato de ele estar em destaque não mudam o limite da tarefa.
Em outro cenário, a aplicação mostra “Descrição obrigatória” dentro do mesmo modal. O agente identifica que a etapa não concluiu, preenche o campo autorizado e tenta novamente dentro do limite definido para o fluxo. Se o aviso persistir, registra a falha em vez de entrar em um ciclo de cliques.
A validação final procura o orçamento em rascunho associado à ordem correta, sem evidência de envio. A equipe pode reproduzir essas situações em um ambiente de teste com dados fictícios. O caso ilustra decisões de projeto e não afirma resultados obtidos por uma assistência real.
Erros comuns
- Chamar qualquer janela de alerta nativo. Um modal HTML não será resolvido pelo mesmo mecanismo de um
confirmde JavaScript. - Instalar um manipulador que só escreve no log. Em diálogos nativos, a rotina precisa dar um desfecho apropriado ao evento.
- Aceitar tudo para evitar travamento. Fluidez técnica não justifica uma decisão comercial não autorizada.
- Forçar clique no fundo da página. O bloqueio pode estar pedindo uma decisão indispensável para continuar.
- Confundir fechamento com sucesso. O desaparecimento da caixa não comprova persistência nem envio correto.
- Repetir a operação após resposta incerta. Confira o estado antes de executar novamente uma ação que pode já ter ocorrido.
O plano de testes do agente deve incluir diálogo conhecido, mensagem nova, dois botões com o mesmo texto, validação que mantém a caixa aberta e falha após confirmação. Teste também a recusa correta: o agente precisa parar quando a decisão excede a autorização, mesmo que saiba tecnicamente qual botão concluiria o fluxo.
Para avaliar o resultado, registre separadamente o reconhecimento do bloqueio, a decisão tomada e a comprovação da transição. Um teste pode acertar o tipo de diálogo e errar a política de negócio. Separar essas evidências ajuda a corrigir a causa sem substituir o modelo por tentativa.
Perguntas frequentes
Todo modal pode ser fechado com Escape?
Não conte com isso como regra operacional. O comportamento depende da implementação e do tipo de superfície. Mesmo quando Escape fecha a caixa, a equipe precisa entender se isso cancela, preserva ou descarta alterações e se essa consequência está autorizada.
Um diálogo com papel ARIA correto é seguro?
O papel ajuda a identificar o componente e apoiar acessibilidade. Ele não comprova a legitimidade do conteúdo, a correção do sistema nem a autorização de uma operação. Continue verificando origem, registro e efeito esperado antes da resposta.
O Playwright trata alertas nativos automaticamente?
A documentação informa que diálogos são dispensados automaticamente quando não há um ouvinte registrado. Ao registrar um ouvinte, a rotina deve resolver o diálogo. Esse comportamento técnico precisa ser considerado no desenho do teste, sem ser confundido com uma política comercial aprovada.
Posso usar a mesma resposta para mensagens parecidas?
Somente quando a equipe definiu e testou que representam a mesma decisão sob as mesmas condições. “Salvar alterações” e “Descartar alterações” compartilham palavras, mas têm efeitos opostos. Compare significado e contexto, além de trechos de texto.
Como relatar um bloqueio ao responsável?
Informe a tarefa, o registro identificado, a mensagem relevante e a decisão necessária. Acrescente o estado conhecido da operação, como “rascunho preenchido, envio não confirmado”. Evite afirmar que nada foi alterado quando a ferramenta perdeu a confirmação do resultado.
