Émulation de fenêtre active et état de visibilité

BotBrowser peut maintenir un contexte déclaré dans un état actif, notamment document.visibilityState === "visible" et document.hidden === false lorsque --bot-always-active est activé. Cette capacité est plus étroite qu’une fenêtre de bureau au premier plan, qu’une personne, qu’une identité ou qu’une garantie d’affichage physique. La documentation de la fenêtre active décrit le paramètre et sa valeur par défaut ; cet article ajoute la sémantique de focus et de Page Visibility, un fixture headless/headful et une preuve minimale. Consultez aussi les bases du fingerprinting.

TL;DR

• focus et blur décrivent des changements de focus ; visibilitychange, document.visibilityState et document.hidden décrivent la visibilité du document.
• --bot-always-active conserve des schémas actifs protégés dans BotBrowser PRO et supérieur, mais actif ne signifie ni humain, ni unique, ni fiable, ni forcément au premier plan.
• Comparez headless et headful avec le même profil, la même page et le même fixture. Enregistrez l’état, les compteurs et un résultat borné, jamais le contenu ni les identifiants.
• Un navigateur ordinaire peut signaler hidden pour un onglet en arrière-plan, une fenêtre réduite ou un document non visible. La séquence dépend du navigateur et de la plateforme.
• Si le paramètre est absent ou désactivé, acceptez le résultat ordinaire et gardez un repli produit ; ne fabriquez pas une preuve de présence humaine.

Contents

• Focus et Page Visibility sont différents
• Ce que change l’émulation de fenêtre active
• Construire un fixture à trois modes
• Lire visibilityState et document.hidden
• Employer le paramètre et son repli
• Réduire les preuves et les affirmations de confidentialité
• Diagnostiquer le premier champ divergent
• Practical conclusion

Focus et Page Visibility sont différents

La spécification W3C Page Visibility 2 définit le modèle de visibilité et l’événement visibilitychange. Elle indique si le document est visible pour le navigateur, pas si une personne regarde, si la fenêtre reçoit le clavier ou si l’écran est allumé. Le guide MDN Page Visibility API décrit également les onglets en arrière-plan et les fenêtres réduites comme des transitions de cycle de vie.

focus et blur appartiennent à une autre couche. Le focus de fenêtre concerne la réception des entrées ; le focus d’élément concerne le contrôle qui reçoit le clavier. Une fenêtre peut perdre le focus sans que le document devienne caché, et un document visible peut n’avoir aucun élément focalisé. Chaque événement reste une observation, jamais une preuve d’attention, d’identité ou d’autorisation.

Pour comparer le contexte d’affichage, associez ce fixture à la politique device pixel ratio et aux propriétés d’écran et de viewport ; ces pages couvrent la géométrie, tandis qu’ici le cycle de vie est central.

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

Cette distinction complète les docs de fenêtre active : ceux-ci expliquent la configuration, tandis que cet article fixe le sens de chaque signal et une vérification répétable.

Ce que change l’émulation de fenêtre active

Avec --bot-always-active, BotBrowser conserve le comportement protégé d’une fenêtre active même lorsque la fenêtre hôte perd le focus. La documentation indique une activation par défaut en PRO et une compatibilité headless et headful. Il s’agit du comportement d’un contexte autorisé, pas d’un rapport sur une personne ou un bureau.

La page peut voir visibilityState rester visible, hidden rester false et aucune transition de visibilité après une perte de focus hôte. Les événements de focus ont leur propre calendrier. Le fixture doit donc enregistrer les valeurs lues. Le paramètre n’ajoute pas une API absente, ne corrige pas l’application et ne garantit pas un affichage physique au premier plan. La référence Document.visibilityState décrit une valeur instantanée ; visibilitychange signale sa modification.

Construire un fixture à trois modes

Utilisez une page de même origine avec trois modes déclarés : headless avec émulation, headful avec émulation et onglet headful sans focus avec le paramètre désactivé. Conservez profil, version et révision de page identiques. Le script suivant ne conserve que des observations bornées.

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 dernière ligne est volontairement conditionnelle : si le runner ne peut pas retirer le focus, notez action-unavailable plutôt que d’inventer hidden. BotBrowser peut rejouer le fixture autorisé et capturer le JSON ; le résultat reste limité à un contexte et un profil. Pour séparer cycle de vie et visibilité, voyez la résilience des contextes longs.

Lire visibilityState et document.hidden

Lisez document.visibilityState dans visibilitychange ; document.hidden est sa forme booléenne. Ne réutilisez pas une valeur obtenue au chargement pour décider d’une reprise. Le propriétaire de la tâche doit empêcher qu’un retour visible ne ressuscite une tâche terminée.

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();
});

Le code montre une règle de propriété, pas une politique universelle. Un lecteur multimédia peut suivre une préférence, alors qu’un éditeur doit conserver les sauvegardes locales. Gardez focusEvents, blurEvents et visibilityChanges séparés.

Headless, headful et onglet sans focus

Headless et headful sont des modes d’exécution, pas des états de présence. Une fenêtre headful peut être couverte ou réduite ; un onglet sans focus peut rester visible dans certains agencements. Exécutez le même profil et consignez mode, action demandée, valeur observée et résultat. visible ne prouve pas qu’une personne regarde ; hidden n’explique pas qui a changé d’onglet.

Le guide Page Visibility API relie visibilité, timers et travail en arrière-plan. Une différence temporelle ne doit pas devenir un classifieur d’identité. Testez le résultat applicatif et le nettoyage, pas un délai supposé humain.

Employer le paramètre et son repli

--bot-always-active=false sert de contrôle de visibilité ordinaire. Vérifiez entitlement, arguments effectifs et profil avant d’interpréter une différence. Enregistrez séparément flagRequested, flagEffective et fallback. BotBrowser peut rejouer le fixture autorisé et observer le résultat, mais ne peut pas prouver une présence humaine ni l’état d’une fenêtre physique. Si le paramètre est indisponible, laissez le navigateur gérer ses événements et conservez pause, sauvegarde et reprise.

La référence des fonctions avancées documente les schémas protégés. Il s’agit d’une fonction de cohérence pour un contexte autorisé, pas d’une promesse de premier plan ou de continuité d’identité.

Réduire les preuves et les affirmations de confidentialité

Conservez un relevé court comme celui-ci et supprimez les traces illimitées :

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

La version, le système, la révision du profil et la date peuvent rester dans les métadonnées de test. N’enregistrez pas comptes, chemins privés, texte DOM, frappes ni identifiants intersites. Actif n’est pas humain, actif n’est pas identité et actif ne garantit pas le premier plan. Les règles d’usage responsable BotBrowser encadrent autorisation et conservation.

Diagnostiquer le premier champ divergent

Commencez par la configuration : si flagEffective est faux, vérifiez licence, argument et profil. S’il est vrai mais que visibilityState change, comparez mode et action de l’hôte. Si blurEvents augmente sans visibilityChanges, il y a perte de focus sans transition de document. Lorsqu’une transition existe, lisez l’état dans le handler et vérifiez qu’une tâche terminée ne reprend pas.

Une transmission utile contient fixtureId, mode, flag effectif, premier champ différent, branche attendue et observée, puis l’action suivante. N’envoyez pas d’identifiants ou d’informations de compte pour rendre le test plus réaliste.

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

Considérez l’émulation de fenêtre active comme un contrôle de cohérence borné. Utilisez visibilitychange, document.visibilityState et document.hidden pour le cycle du document, et gardez focus et blur dans leur couche d’interaction. Comparez les trois modes, testez --bot-always-active=false, réduisez les preuves et rappelez-vous que l’état actif ne démontre ni humain, ni identité, ni consentement, ni premier plan garanti.