Screen Wake Lock : cycle de vie et limites de confidentialité
Gérer le wake lock avec reprise de visibilité, libération explicite et solution de repli.
BotBrowser Team
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Screen Wake Lock permet de demander au navigateur de ne pas assombrir l’écran pendant une tâche visible. L’autorisation est temporaire et médiée par le navigateur : visibilité, politique, énergie ou libération explicite peuvent y mettre fin. BotBrowser valide ces chemins dans des profils contrôlés, mais ne maintient pas un écran physique allumé et ne garantit pas un support universel.
TL;DR
- Détecter
navigator.wakeLocket demander seulement pour une tâche visible. - Conserver le
WakeLockSentinel, écouterreleaseet libérer à la fin. - Reprendre après
visibilitychangeuniquement si la tâche continue et que la capacité existe. - Ce n’est ni une exécution en arrière-plan, ni un accès à la batterie, ni une preuve d’identité.
Contents
Demander et libérer
Appelez navigator.wakeLock.request('screen') dans un parcours explicite. Traitez le refus comme un résultat normal et rendez le nettoyage idempotent lorsque la tâche se termine ou que l’utilisateur choisit l’économie d’énergie.
Visibilité et confidentialité
Le navigateur peut libérer le verrou quand le document est masqué. Au retour, vérifiez l’état courant avant toute nouvelle demande et gardez les contrôles habituels si elle échoue. L’API ne révèle ni batterie ni identité matérielle ; limitez la télémétrie au but et au résultat.
Tester avec BotBrowser
BotBrowser peut valider dans un profil isolé les étapes précises de détection de capacité, de demande screen, de libération explicite, de l’événement release et de reprise après visibilitychange. Vous pouvez ainsi vérifier qu’une fixture de présentation ou de checklist affiche le bon état et ne redemande pas le verrou lorsque la tâche est terminée. BotBrowser ne contrôle pas la politique d’alimentation du système, ne mesure pas la batterie, ne maintient pas un écran physique allumé et ne garantit pas la prise en charge sur tous les runners. Testez l’API absente, le refus, le nettoyage répété et le repli.
Conclusion
Considérez le wake lock comme un bail bref : détecter, libérer, reprendre après visibilité et conserver un repli. Références : W3C, MDN, WakeLockSentinel, Privacy Principles et BotBrowser.
À lire ensuite
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.