.4UVmK5aw_1uGpNi.svg){kind=small}
.AzQB9McO_PVSYK.svg){kind=small}
.DjhlE8MO_Z1DYVxU.svg){kind=small}
.DM2pllEO_1cxFXE.svg){kind=small}
.CvN5042A_Z10D5qc.svg){kind=small}
.Dcqs_gC__NRL3p.svg){kind=small}
TimeoutError: waiting for selector no passo 14 de 20
As sessões são gratuitas — pague apenas pelo tráfego
Navegador na nuvem com modo de interface
Abra exatamente essa sessão em uma aba de um navegador real e simplesmente olhe. Seja qual for o estado da página quando algo deu errado, é isso que você vê.
- Abra uma visualização ao vivo de uma sessão em andamento, em vez de executar o job de novo para reproduzir a falha
- Passe um CAPTCHA difícil ou um pedido inesperado de 2FA para uma pessoa e deixe o script se reconectar depois
- Os cookies e o estado da página continuam como estavam — só a conexão muda
Modo de interface
Abra a sessão
em um navegador real.
Qualquer sessão em execução pode ser aberta em uma visualização ao vivo: o mesmo navegador que o script estava controlando, em uma aba sua. Faça manualmente o que o script não consegue e depois devolva o controle.
Por que o modo de interface importa em um navegador na nuvem
Um script headless que quebra no meio do caminho geralmente só entrega um stack trace. Talvez um número de linha. Boa sorte para descobrir qual clique realmente falhou no passo catorze de vinte, ou se a página sequer carregou como deveria.
O navegador na nuvem com modo de interface oferece outra opção: abrir exatamente essa sessão em uma aba de um navegador real e simplesmente olhar. Seja qual for o estado da página quando algo deu errado, é isso que você vê – sem precisar reconstruir tudo depois a partir da saída do console, nem executar o job inteiro cinco vezes na esperança de uma mensagem de erro mais clara.
Isso costuma fazer mais diferença em logins com etapas extras, formulários que mudam conforme as respostas anteriores e fluxos de checkout. Basicamente, em qualquer lugar onde um popup inesperado pode quebrar silenciosamente um script que funcionava bem uma hora antes, e ninguém criou uma regra para esse popup específico porque ninguém o esperava.
Principais recursos do modo visual
A visualização ao vivo serve a diferentes tarefas, dependendo do motivo pelo qual você precisa dela. Às vezes é para pegar um bug, às vezes é para contorná-lo.
Depuração de scripts em tempo real (depuração ao vivo)
Uma execução travada ou com falha geralmente não significa que a sessão morreu. Muitas vezes ela continua lá, só desconectada de tudo. Abra uma visualização ao vivo e você olha direto para ela, no meio da falha, em vez de adivinhar por um arquivo de log como a página provavelmente estava naquele momento.
Isso também revela problemas que nunca geram um erro claro – uma página que carregou pela metade, uma mudança de layout que tirou um botão do lugar na hora do clique, um modal que apareceu meio segundo tarde demais.
Controle interativo da sessão (humano no processo)
Certas coisas um script simplesmente não consegue superar sozinho – um CAPTCHA difícil, um pedido inesperado de 2FA, alguma verificação de segurança com a qual ninguém contava. Quando isso acontece, a conexão da automação é encerrada, uma visualização ao vivo é aberta para a mesma sessão e alguém resolve manualmente a parte chata.
Depois disso, o script se reconecta e continua de onde parou. Cookies, estado da página, tudo permanece como estava – só a conexão mudou. Isso vale igualmente para sessões que usam uma configuração antidetecção: mesmo com um fingerprint convincente e indetectável, um navegador antidetecção ainda pode cair em uma verificação que só uma pessoa de verdade consegue resolver.
Gravação de sessões e capturas de tela
Assistir a uma sessão ao vivo só ajuda se você estiver presente quando ela acontece. Quase toda depuração acaba precisando de algo para analisar depois – uma captura de tela do momento em que as coisas quebraram, uma gravação completa da sessão, um log de rede para conferir o que realmente foi enviado e recebido.
Nem toda plataforma de navegador na nuvem oferece os três recursos da mesma forma, então vale confirmar diretamente com a Floppydata o que é compatível antes de montar um fluxo de trabalho em torno de um formato específico. Uma captura de tela logo antes da falha muitas vezes basta; vídeo e logs de rede mostram seu valor nos casos mais difíceis, em que nada visual explica o que deu errado.
Onde isso é realmente usado
Algumas situações aparecem o tempo todo e nem sempre se parecem à primeira vista:
-
Fluxos de cadastro e verificações antifraude no checkout
Fluxos de cadastro com verificação por SMS ou páginas de checkout que de vez em quando disparam uma verificação antifraude – chatos de contornar por script, mas rápidos de resolver manualmente uma vez.
-
Distinguir um bug real de um seletor instável
Equipes de QA verificando se um teste end-to-end com falha é um bug real ou apenas um seletor instável, em vez de reexecutar toda a suíte às cegas.
-
Reproduzir o que um cliente descreveu
Equipes de suporte reproduzindo um bug que um cliente descreveu, mas não conseguiu registrar direito em uma captura de tela.
-
Confirmar que a página foi renderizada como esperado
Jobs de scraping confirmando que a página foi realmente renderizada como o seletor espera, antes de supor que o seletor está quebrado.
-
Mostrar funcionando ao vivo
Demonstrações para clientes, em que mostrar algo funcionando ao vivo vale mais do que pedir que alguém confie em um log de terminal.
Como ativar a interface / o visualizador ao vivo no seu script
Uma sessão não pode ter uma conexão de automação e uma visualização ao vivo ao mesmo tempo. Fechar uma abre espaço para a outra, e voltar depois leva praticamente o mesmo tempo que levou para trocar:
- O script se desconecta da sessão atual.
- Uma visualização ao vivo é solicitada para essa mesma sessão e aberta em uma aba do navegador.
- Uma pessoa resolve o que for necessário – um CAPTCHA, um código 2FA, uma tela de consentimento pontual.
- O script solicita uma nova conexão com a sessão e retoma exatamente de onde parou.
live-view.js
await browser.close(); // hand off to a human// POST /v2/browser/sessions/{id}/live-view -> { liveViewUrl }// person opens liveViewUrl, solves the CAPTCHA / 2FA prompt// GET /v2/browser/sessions/{id} -> fresh connectUrl, script resumesTanto connectUrl quanto liveViewUrl devem ser tratados como senhas: não os registre em nenhum log, não os cole em um ticket de suporte e solicite um novo link em vez de manter um link antigo por mais tempo do que o necessário.