Emulación de ventana activa y estado de visibilidad

BotBrowser puede mantener un contexto declarado en estado activo, incluido document.visibilityState === "visible" y document.hidden === false cuando se habilita --bot-always-active. Esa capacidad es más estrecha que una ventana de escritorio en primer plano, una persona, una identidad o una garantía de pantalla visible. La documentación de ventana activa cubre la opción y su valor predeterminado; este artículo añade la diferencia semántica entre foco y Page Visibility, un fixture para headless/headful y evidencia mínima. Consulta también fundamentos de fingerprinting.

TL;DR

• focus y blur describen cambios de foco; visibilitychange, document.visibilityState y document.hidden describen la visibilidad del documento.
• --bot-always-active mantiene patrones activos protegidos en BotBrowser PRO y superiores, pero activo no significa humano, único, confiable ni necesariamente en primer plano.
• Compara ejecuciones headless y headful con el mismo perfil, página y fixture. Registra estado, contadores y resultado acotado, nunca contenido o identificadores.
• Un navegador normal puede mostrar hidden para una pestaña de fondo, una ventana minimizada o un documento no visible. La secuencia depende del navegador y la plataforma.
• Si la opción no existe o se desactiva, permite el resultado normal y conserva un respaldo del producto; no fabriques una afirmación de actividad humana.

Contents

• Foco y Page Visibility no son lo mismo
• Qué cambia la emulación de ventana activa
• Construir un fixture de tres modos
• Leer visibilityState y document.hidden
• Usar la opción y su respaldo
• Minimizar evidencia y afirmaciones de privacidad
• Diagnosticar el primer campo divergente
• Practical conclusion

Foco y Page Visibility no son lo mismo

La especificación W3C Page Visibility 2 define el modelo de visibilidad y visibilitychange. Responde si el documento es visible para el navegador, no si alguien observa la pantalla, si la ventana recibe teclado o si el monitor está encendido. La guía de MDN Page Visibility API incluye pestañas en segundo plano y ventanas minimizadas como cambios de ciclo de vida.

focus y blur pertenecen a otra capa. El foco de ventana indica quién recibe la entrada, mientras el foco de elemento indica qué control recibe teclado. Una ventana puede perder foco sin que el documento pase a oculto; un documento visible puede no tener control enfocado. Cada evento debe ser una observación independiente, no una prueba de atención o identidad.

Para comparar el contexto de pantalla, combina este fixture con la política de device pixel ratio y las propiedades de pantalla y viewport; esas páginas cubren geometría y esta cubre el ciclo de vida.

Signal	Browser meaning	Not proven
focus / blur	A window or focused element changed focus	Human attention, identity, or physical foreground
visibilitychange	The document visibility state changed	Monitor power, user intent, or reading
document.visibilityState	Current document state such as visible or hidden	A universal platform state across browsers
document.hidden	Boolean convenience view of document visibility	Human presence or trust

Esta separación es el valor añadido frente a los docs de ventana activa: aquí se define el significado de cada señal y una prueba reproducible.

Qué cambia la emulación de ventana activa

Con --bot-always-active, BotBrowser conserva patrones de ventana activa aunque la ventana anfitriona pierda foco. La documentación indica que se activa por defecto en PRO y funciona en headless y headful. Es un comportamiento del contexto autorizado, no un informe sobre una persona o un escritorio.

La página puede observar visibilityState como visible, hidden como false y ningún cambio de visibilidad cuando el anfitrión pierde foco. Los eventos de foco pueden mantener otra cadencia. Por eso el fixture debe registrar valores leídos y no asumir que todo evento desaparece. La opción tampoco añade API ausente, corrige una aplicación ni garantiza una ventana física en primer plano. Document.visibilityState es una instantánea; visibilitychange avisa de su modificación.

Construir un fixture de tres modos

Usa una página del mismo origen y tres modos declarados: headless con emulación, headful con emulación y una pestaña headful sin foco con la opción desactivada. Mantén perfil, versión y revisión de página constantes. El script siguiente guarda únicamente observaciones acotadas.

const result = {
  fixtureId: 'visibility-boundary-01',
  flag: 'unknown',
  visibilityState: document.visibilityState,
  hidden: document.hidden,
  focusEvents: 0,
  blurEvents: 0,
  visibilityChanges: 0,
  outcome: 'initial',
};

window.addEventListener(
  'focus',
  () => {
    result.focusEvents += 1;
  },
  { passive: true }
);
window.addEventListener(
  'blur',
  () => {
    result.blurEvents += 1;
  },
  { passive: true }
);
document.addEventListener('visibilitychange', () => {
  result.visibilityChanges += 1;
  result.visibilityState = document.visibilityState;
  result.hidden = document.hidden;
});

window.sampleVisibility = flag => ({
  ...result,
  flag,
  visibilityState: document.visibilityState,
  hidden: document.hidden,
  outcome: 'sampled',
});

Mode	Flag	Host action	Expected record shape
Headless	enabled	No desktop window	visible, false, bounded events
Headful	enabled	Unfocus host window	visible, false, bounded events
Headful	disabled	Switch to another tab	hidden or visible according to browser context

La última fila es deliberadamente condicional: un runner que no puede desenfocar una ventana debe registrar action-unavailable, no inventar hidden. BotBrowser puede repetir el fixture autorizado y capturar el JSON, pero el resultado describe un contexto y perfil, no un detector externo. Para separar ciclo de vida y visibilidad, consulta resiliencia de contextos largos.

Leer visibilityState y document.hidden

Lee document.visibilityState dentro de visibilitychange; document.hidden es su forma booleana. No conserves un valor de carga para decidir si reanudar trabajo. El dueño de la tarea debe impedir que una transición visible resucite una tarea terminada.

let taskActive = false;

function readVisibility() {
  return {
    state: document.visibilityState,
    hidden: document.hidden,
  };
}

document.addEventListener('visibilitychange', () => {
  const current = readVisibility();
  if (current.hidden) pauseOwnedTask();
  else if (taskActive) resumeOwnedTask();
});

El código expresa una política de propiedad, no una regla universal. Un reproductor puede seguir una preferencia, mientras un editor debe conservar guardados locales. focusEvents, blurEvents y visibilityChanges deben permanecer como contadores separados.

Headless, headful y una pestaña sin foco

Headless y headful son modos de ejecución, no estados de presencia. Una ventana headful puede estar cubierta o minimizada; una pestaña sin foco puede seguir visible en ciertos diseños. Ejecuta el mismo perfil y registra modo, acción solicitada, valor observado y resultado. El valor visible no demuestra que alguien mire la pantalla; hidden no explica quién cambió de pestaña.

La guía Page Visibility API relaciona visibilidad con timers y trabajo de fondo. No conviertas una diferencia de tiempo en clasificación de identidad. Prueba limpieza y resultado de la aplicación, no milisegundos supuestamente humanos.

Usar la opción y su respaldo

--bot-always-active=false sirve como control de visibilidad ordinaria. Verifica entitlement, argumentos efectivos y perfil antes de interpretar una diferencia. Registra flagRequested, flagEffective y fallback por separado. BotBrowser puede repetir el fixture autorizado y observar el resultado, pero no puede demostrar presencia humana ni el estado de una ventana física. Si la opción no está disponible, deja que el navegador medie sus eventos y conserva botones de pausar, guardar y reintentar.

La referencia de funciones avanzadas documenta los patrones protegidos. Es una función de consistencia para un contexto autorizado, no una promesa de primer plano ni continuidad de identidad.

Minimizar evidencia y afirmaciones de privacidad

Conserva un registro corto como el siguiente y elimina trazas sin límites:

{
  "fixtureId": "visibility-boundary-01",
  "browserMode": "headful",
  "flagEffective": true,
  "visibilityState": "visible",
  "hidden": false,
  "focusEvents": 1,
  "blurEvents": 1,
  "visibilityChanges": 0,
  "outcome": "stable-visible"
}

Puedes guardar versión, sistema, revisión de perfil y fecha en metadatos de prueba. No guardes cuentas, rutas privadas, texto DOM, teclas ni identificadores entre sitios. Activo no es humano, activo no es identidad y activo no garantiza primer plano. La guía de uso responsable de BotBrowser rige autorización y retención.

Diagnosticar el primer campo divergente

Empieza por configuración: si flagEffective es falso, comprueba licencia, argumento y perfil. Si es verdadero pero cambia visibilityState, compara modo y acción del host. Si blurEvents aumenta sin visibilityChanges, hubo pérdida de foco sin transición de documento. Si hay transición, lee el estado dentro del handler y comprueba que una tarea terminada no se reanude.

Una entrega útil contiene fixtureId, modo, flag efectivo, primer campo distinto, rama esperada y observada, y siguiente acción. No envíes credenciales ni datos de cuenta para hacer que la prueba parezca real.

Public sources

• W3C Page Visibility 2
• MDN: Page Visibility API
• MDN: Document.visibilityState
• BotBrowser: Active Window Emulation
• BotBrowser: Advanced Features, active-window emulation
• BotBrowser: Responsible Use

Practical conclusion

Trata la emulación como un control de consistencia acotado. Usa visibilitychange, document.visibilityState y document.hidden para el ciclo del documento, y conserva focus y blur en su propia capa. Compara los tres modos, prueba --bot-always-active=false, minimiza evidencia y recuerda que activo no demuestra humano, identidad, consentimiento ni primer plano garantizado.