Les service workers d'extension peuvent désormais rester actifs tant qu'ils reçoivent des événements. Cela augmente la fiabilité des agents des services d'extension, mais présente un écueil que vous devez éviter.
À partir de Chrome 110 (version bêta disponible depuis le 7 février 2023), les service workers d'extension restent actifs tant qu'ils reçoivent des événements. Cela corrige un problème de synchronisation dans l'implémentation précédente des service workers d'extension. Il était possible que des délais d'inactivité se produisent lorsque de nouveaux événements se trouvaient dans la file d'attente d'événements et que ces délais d'inactivité tronquent le travail asynchrone. Cette amélioration supprime la durée de vie maximale de cinq minutes pour les nœuds de calcul de service d'extension.
Cet article décrit comment ces comportements ont changé.
Contexte
Les service workers d'extension se comportent principalement comme des service workers Web, mais en plus des événements de service worker, ils peuvent également écouter les événements d'extension. Bien que les événements de service worker normaux prolongent la durée de vie du service worker, avant la version 110, seuls quelques événements de plate-forme d'extension permettaient de maintenir un service worker d'extension.
Normalement, Chromium arrête un service worker lorsqu'une des conditions suivantes est remplie:
- Le service worker n'a pas reçu d'événement depuis plus de 30 secondes et aucune tâche de longue durée n'est en cours. Si un service worker a reçu un événement pendant ce délai, le minuteur d'inactivité a été supprimé.
- Une tâche de longue durée a pris plus de cinq minutes à s'exécuter, et aucun événement n'a été reçu au cours des 30 dernières secondes.
Les nouveaux événements de service worker reçus avant l'expiration du minuteur d'inactivité ou du minuteur de tâche de longue durée réinitialisent les minuteurs et prolongent la durée de vie du service worker.
Malheureusement, ce comportement ne s'appliquait pas aux événements d'extension. Les événements d'extension pouvaient réveiller un service worker d'extension et le maintenir en vie jusqu'à la fin de l'événement, mais ils ne pouvaient pas prolonger le délai d'inactivité de 30 secondes. Cela signifiait en fait que les services workers d'extension pouvaient être arrêtés à tout moment après la fin du dernier événement de l'extension, même si le navigateur venait de distribuer un nouvel événement à l'extension.
Modifications apportées
À partir de Chrome 110, tous les événements réinitialisent le minuteur d'inactivité et le délai d'inactivité ne se produit pas s'il existe des événements en attente. En d'autres termes, en l'absence d'interruptions inattendues, les workers de service d'extension restent généralement actifs tant qu'ils traitent activement des événements. De plus, les appels d'API Chrome spécifiques aux extensions, telles que chrome.storage.local.get(), réinitialisent le délai d'inactivité. Plus spécifiquement :
- Le service worker s'arrête après 30 secondes d'inactivité. (La réception d'un événement ou l'appel d'une API d'extension réinitialise ce minuteur.)
- Le service worker s'arrête si le traitement d'une seule requête, telle qu'un événement ou un appel d'API, prend plus de cinq minutes.
Certaines API, comme la messagerie native, fournissent un délai avant expiration fort qui annule ces deux délais.
Nous nous efforçons toujours de nous assurer que les nœuds de calcul du service d'extension sont arrêtés dans la mesure du possible, sans arrêter les tâches de longue durée. Les workers de service d'extension respectueux des ressources doivent toujours céder la priorité dans la mesure du possible. De plus, les extensions doivent se préparer à une interruption inattendue en conservant l'état. Cela permet de se protéger contre les événements imprévisibles, comme la fermeture forcée du navigateur par l'utilisateur.
Photo de Paula Guerreiro sur Unsplash