Detectar usuários inativos com a API Idle Detection

Use a API Idle Detection para descobrir quando o usuário não está usando o dispositivo ativamente.

Thomas Steiner

O que é a API Idle Detection?

A API Idle Detection notifica os desenvolvedores quando um usuário está inativo, indicando itens como falta de interação com o teclado, o mouse, a tela, a ativação de um protetor, o bloqueio da tela ou a mudança para outra tela. Um limite definido pelo desenvolvedor aciona a notificação.

Casos de uso sugeridos para a API Idle Detection

Exemplos de sites que podem usar essa API incluem:

• Aplicativos de chat ou sites de rede social on-line podem usar essa API para permitir que o usuário saiba se os contatos dele estão acessíveis no momento.
• Os aplicativos de quiosque expostos publicamente, por exemplo, em museus, podem usar essa API para retornar à visualização "página inicial" se ninguém mais interagir com o quiosque.
• Apps que exigem cálculos caros, por exemplo, para desenhar gráficos, podem limitar esses cálculos aos momentos em que o usuário interage com o dispositivo.

Status atual

Step	Status
1. Criar explicação	Concluído
2. Criar rascunho inicial da especificação	Concluído
3. Reunir feedbacks e iterar no design	Em andamento
4. Teste de origem	Concluído
5. Lançamento	Chromium 94

Como usar a API Idle Detection

Detecção de recursos

Para verificar se há suporte para a API Idle Detection, use:

if ('IdleDetector' in window) {
  // Idle Detector API supported
}

Conceitos da API Idle Detection

A API Idle Detection presume que há algum nível de engajamento entre o usuário, o user agent (ou seja, o navegador) e o sistema operacional do dispositivo em uso. Isso é representado em duas dimensões:

• O estado de inatividade do usuário: active ou idle: o usuário interagiu ou não com o user agent por um período.
• O estado de inatividade da tela:locked ou unlocked: o sistema tem um bloqueio de tela ativo (como um protetor de tela) que impede a interação com o user agent.

Distinguir active de idle exige heurística que pode diferir entre usuário, user agent e sistema operacional. Também precisa ser um limite razoavelmente aproximado (consulte Segurança e permissões).

O modelo não faz distinção formal entre a interação com um conteúdo específico (ou seja, a página da Web em uma guia usando a API), o user agent como um todo ou o sistema operacional. Essa definição é deixada para o user agent.

Como usar a API Idle Detection

A primeira etapa ao usar a API Idle Detection é garantir que a permissão 'idle-detection' seja concedida. Se a permissão não for concedida, será necessário solicitá-la usando IdleDetector.requestPermission(). Observe que chamar esse método requer um gesto do usuário.

// Make sure 'idle-detection' permission is granted.
const state = await IdleDetector.requestPermission();
if (state !== 'granted') {
  // Need to request permission first.
  return console.log('Idle detection permission not granted.');
}

Observação:inicialmente, a detecção de inatividade era controlada por trás da permissão de notificações. Embora muitos casos de uso dessa API envolvem notificações, os editores de especificações de detecção de inatividade decidiram protegê-la com uma permissão dedicada de detecção de inatividade.

A segunda etapa é instanciar o IdleDetector. O threshold mínimo é de 60.000 milissegundos (1 minuto). É possível finalmente iniciar a detecção de inatividade chamando o método start() do IdleDetector. Ele usa um objeto com o threshold inativo desejado em milissegundos e um signal opcional com um AbortSignal para cancelar a detecção de inatividade como parâmetros.

try {
  const controller = new AbortController();
  const signal = controller.signal;

  const idleDetector = new IdleDetector();
  idleDetector.addEventListener('change', () => {
    const userState = idleDetector.userState;
    const screenState = idleDetector.screenState;
    console.log(`Idle change: ${userState}, ${screenState}.`);
  });

  await idleDetector.start({
    threshold: 60000,
    signal,
  });
  console.log('IdleDetector is active.');
} catch (err) {
  // Deal with initialization errors like permission denied,
  // running outside of top-level frame, etc.
  console.error(err.name, err.message);
}

Cancele a detecção de inatividade chamando o método abort() do AbortController.

controller.abort();
console.log('IdleDetector is stopped.');

Suporte ao DevTools

A partir do Chromium 94, é possível emular eventos inativos no DevTools sem estar realmente inativo. No DevTools, abra a guia Sensors e procure a opção Emulate inativo Detector state. Veja as várias opções no vídeo abaixo.

Emulação de estado do detector inativo no DevTools.

Suporte para Puppeteer

A partir do Puppeteer versão 5.3.1, é possível emular os vários estados inativos para testar de maneira programática como o comportamento do app da Web muda.

Demonstração

Confira a API Idle Detection em ação com a demonstração da tela temporária, que apaga o conteúdo após 60 segundos de inatividade. Você pode imaginar isso sendo implantado em uma loja de departamentos para que as crianças possam desenhar.

Polipreenchimento

Alguns aspectos da API Idle Detection são bibliotecas de detecção de inatividade e polyfillable, como idle.ts, mas essas abordagens são limitadas à área de conteúdo do próprio app da Web: a biblioteca em execução no contexto do app da Web precisa pesquisar com alto nível de eventos de entrada ou detectar mudanças de visibilidade. De forma mais restritiva, no entanto, as bibliotecas não conseguem dizer hoje quando um usuário fica inativo fora da área de conteúdo (por exemplo, quando um usuário está em uma guia diferente ou saiu do computador completamente).

Segurança e permissões

A equipe do Chrome projetou e implementou a API Idle Detection usando os princípios fundamentais definidos em Como controlar o acesso a recursos avançados da plataforma Web, incluindo controle do usuário, transparência e ergonomia. A capacidade de usar essa API é controlada pela permissão 'idle-detection'. Para usar a API, o app também precisa estar em execução em um contexto seguro de nível superior.

Controle e privacidade do usuário

Sempre queremos impedir que agentes maliciosos usem indevidamente as novas APIs. Sites aparentemente independentes, mas que são controlados pela mesma entidade, podem receber informações de usuários inativos e correlacionar os dados para identificar usuários únicos em origens diferentes. Para reduzir esse tipo de ataque, a API Idle Detection limita a granularidade dos eventos inativos informados.

Feedback

A equipe do Chrome quer saber mais sobre suas experiências com a API Idle Detection.

Fale sobre o design da API

Algo na API não funciona como você esperava? Ou há métodos ou propriedades ausentes que você precisa para implementar sua ideia? Tem alguma dúvida ou comentário sobre o modelo de segurança? Registre um problema de especificação no repositório do GitHub correspondente ou adicione suas ideias a um problema atual.

Informar um problema com a implementação

Você encontrou um bug na implementação do Chrome? Ou a implementação é diferente da especificação? Registre um bug em new.crbug.com. Inclua o máximo de detalhes possível, instruções simples para reprodução e insira Blink>Input na caixa Componentes. O Glitch funciona muito bem para compartilhar repetições rápidas e fáceis.

Mostrar suporte à API

Você planeja usar a API Idle Detection? Seu suporte público ajuda a equipe do Chrome a priorizar recursos e mostra a outros fornecedores de navegador como é importante oferecer suporte a eles.

• Conte como você planeja usá-lo na conversa do discurso do WICG (em inglês).
• Envie um tweet para @ChromiumDev com a hashtag #IdleDetection e conte para a gente onde e como você está usando a hashtag.

Links úteis

• Explicações públicas
• Especificação do rascunho
• Demonstração da API de detecção de inatividade | Fonte da demonstração da API de detecção de inatividade
• Rastreamento de bugs
• Entrada ChromeStatus.com
• Componente Blink: Blink>Input

Agradecimentos

A API Idle Detection foi implementada por Sam Goto. O suporte ao DevTools foi adicionado por Maksim Sadym. Agradecemos a Joe Medley, Kayce Basques e Reilly Grant pelas avaliações deste artigo. A imagem principal é de Fernando Hernandez no Unsplash (links em inglês).