Are You Sure Want To Exit

O diálogo "Tem certeza que deseja sair?" na prática

Esse prompt aparece quando o usuário tenta fechar uma aplicação ou sair de uma sessão, e a maior parte dos desenvolvedores trata isso como algo trivial. Não é. A implementação errada faz usuários perderem dados, fecharem janelas sem querer e ficarem frustrados com sistemas que parecem travar porque o diálogo não responde no momento esperado. O problema fundamental é que a maioria das equipes não pensa no fluxo completo. Elas colocam o confirm no evento de fechar e pronto. O resultado é um diálogo que sobrepõe telas de carregamento, que não dispara quando deveria, ou que deixa o programa aberto mesmo após o usuário clicar "Sim".

Como o are you sure want to exit funciona por baixo dos panos

O mecanismo é simples em teoria: interceptar o evento de fechamento da janela, verificar se há alterações não salvas ou ações em progresso, e mostrar uma caixa de confirmação antes de encerrar o processo. A complexidade aparece quando você considera o contexto real de uso. Em aplicações desktop, o evento costuma ser o OnCloseQuery no Delphi, CloseWindow no Windows API, ou handleClose no Electron. Em web, é o beforeunload. Cada um tem um comportamento diferente em relação a como o navegador ou sistema operacional trata a suspensão do processo. O que poucos documentam é que o beforeunload em navegadores modernos só exibe mensagens personalizadas limitadas. Se você tentar mostrar um texto customizado, o navegador ignora e usa o padrão. Isso quebraria qualquer tentativa de colocar instruções específicas no diálogo.

O erro que eu cometi e como corriji

Eu trabalhei numa aplicação de gestão onde o confirm de saída só verificava se o usuário tinha alterações não salvas no formulário atual. Um bug sutil fez com que, em certas condições de rede lenta, o diálogo nem aparecesse. O problema era que o handler de fechamento era disparado antes do último save finishar, e o flag de "dados alterados" já tinha sido resetado pelo callback de sucesso. A solução foi mover a verificação para um evento anterior no ciclo de vida, usar um debounce de 300ms no flag de alterações e, principalmente, adicionar um estado de "salvando" que bloqueava o fechamento até o término. Isso eliminou as perdas de dados quase que completamente. O tempo médio de correção naquele módulo caiu de duas semanas para três dias úteis.

Implementação prática em diferentes plataformas

Web com JavaScript

No navegador, a abordagem padrão usa o evento beforeunload. Você define uma mensagem e retorna a string que o navegador vai exibir. A limitação é que navegadores modernos como Chrome e Firefox substituem sua mensagem por um padrão do sistema. O código básico: window.addEventListener('beforeunload', function(e) { if (hasUnsavedChanges) { e.preventDefault(); e.returnValue = ''; } });

Isso funciona, mas tem um detalhe importante: o evento não dispara se a página for fechada via Task Manager ou se o navegador encontrar um erro crítico. O usuário pode simplesmente matar o processo e perder tudo. Não existe forma confiável de capturar isso no lado do cliente.

Aplicações desktop com Electron

No Electron, o comportamento é diferente porque você tem controle sobre a janela via Node.js. O evento close no BrowserWindow permite cancelar o fechamento com event.preventDefault(). Isso dá mais flexibilidade do que a versão web, mas exige que você gerencie o estado manualmente. Você também precisa lidar com o comando de sair via menu ou atalho de teclado. Esses caminhos muitas vezes ignoram o evento close se não forem capturados separadamente no menu principal.

Aplicações mobile

No Android, o back button dispara onBackPress ou onBackPressed dependendo da versão da biblioteca. No iOS, o swipe ou botão home exige tratamento via navigation stack ou lifecycle events. A regra geral é a mesma: interceptar, verificar, confirmar, mas cada plataforma tem seus próprios pontos de interceptação que mudam entre versões. O primeiro erro é mostrar o diálogo apenas quando há alterações visíveis. Se o usuário está editando um campo que ainda não foi marcado como alterado pelo seu sistema de tracking, o prompt não aparece e os dados somem. O tracking deve considerar qualquer interação com input, select, textarea ou qualquer controle que mude o estado do dado. O segundo erro é não dar ao usuário a opção de cancelar. Se o botão "Não" não fechar o diálogo ou se o clique fora da caixa de diálogo não funcionar como esperado, o usuário fica preso. Em algumas implementações, o foco some e o diálogo fica invisível atrás da janela principal. Isso é particularmente problemático em múltiplos monitores.

O terceiro erro é esquecer o contexto de múltiplas abas ou janelas. Se o usuário abrir três formulários e tentar fechar a aba principal, o diálogo precisa saber que os outros dois também contêm dados não salvos. Simplesmente verificar o estado da janela atual não é suficiente.

Quando NÃO usar o prompt de saída

Existem cenários onde esse diálogo é pior do que benéfico. Aplicações de leitura, visualizadores de imagem, ferramentas de anotação rápida sem salvamento automático — nesses casos, o prompt só atrapalha. O usuário sabe que está saindo e não quer perder tempo com confirmações desnecessárias. Outro caso é em fluxos críticos onde a ação de sair é intencional e comum. Sistemas de autoatendimento, quiosques, caixas de supermarket — aqui o prompt adiciona fricção onde não deveria existir. A melhor abordagem nesses casos é simplesmente encerrar sem questionar.

Alternativas modernas

O que tem funcionado melhor do que o diálogo tradicional é o salvamento automático progressivo. Em vez de perguntar se o usuário quer sair, você salva continuamente enquanto ele trabalha e não precisa de confirmação alguma. Isso elimina o problema raiz. Quando o salvamento automático não é viável — por questões de performance, privacidade ou conformidade — a abordagem híbrida funciona bem: mostre um indicador sutil de "não salvo" junto com um atalho de teclado claro. O usuário que realmente quer sair vai perceber e agir de forma intencional, enquanto o que está navegando normalmente não é interrompido. O prompt de confirmação ainda tem seu lugar em situações onde a perda de dados tem consequências reais, como em formulários médicos, transações financeiras ou documentação legal. Nesses casos, o diálogo é necessário e a implementação deve ser especialmente cuidadosa para não falhar nos momentos em que mais importa.