Les service workers d'extensions peuvent désormais rester actifs tant qu'ils reçoivent des événements. Cela augmente la fiabilité des service workers d'extensions, mais il présente un piège à éviter.
À partir de Chrome 110 (en version bêta au 7 février 2023), les service workers d'extensions restent actifs tant qu'ils reçoivent des événements. Un problème de synchronisation a été résolu dans l'implémentation précédente des service workers d'extensions. Il était possible que des délais d'expiration se produisent lorsque de nouveaux événements se trouvaient dans la file d'attente des événements et que ces délais tronquaient les tâches asynchrones. Cette amélioration supprime la durée de vie maximale stricte de cinq minutes pour les service workers d'extensions.
Cet article décrit les modifications apportées à ces comportements.
Contexte
Les service workers d'extensions se comportent principalement comme des service workers d'extensions, mais en plus des événements de service worker, ils peuvent également écouter ces événements. Alors que les événements de service worker normaux prolongent la durée de vie du service worker, avant la publication de la version 110, seuls quelques événements de plate-forme d'extension maintiennent un service worker d'extension actif.
Normalement, Chromium met fin au service worker lorsque l'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 à ce moment-là, le minuteur d'inactivité a été supprimé.
- L'exécution d'une tâche de longue durée a pris plus de cinq minutes 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'applique pas aux événements d'extension. Les événements d'extension pouvaient réveiller un service worker d'extension et le maintenir actif jusqu'à la fin de l'événement, mais il n'a pas pu prolonger le délai d'inactivité de 30 secondes. Cela signifiait que les service workers d'extensions pouvaient être arrêtés à tout moment après la fin du dernier événement d'extension, même si le navigateur venait d'envoyer un nouvel événement à l'extension.
Modifications apportées
À partir de Chrome 110, tous les événements réinitialisent le délai d'inactivité et le délai d'inactivité ne se produira pas s'il y a des événements en attente. En d'autres termes, en l'absence d'interruptions inattendues, les service workers d'extensions restent actifs tant qu'ils traitent activement les événements. De plus, les appels aux 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 telles que la messagerie native fournissent un message keep-alive fort qui annule ces deux minuteurs.
Nous mettons tout en œuvre pour que les service workers d'extensions soient arrêtés lorsque cela est possible, sans interrompre les tâches de longue durée. Les service workers d'extensions soucieux des ressources doivent toujours céder quand c'est possible. De plus, les extensions doivent se préparer à un arrêt inattendu grâce à un état persistant. Cela permet d'éviter des événements imprévisibles tels que la fermeture forcée du navigateur par l'utilisateur.
Photo de Paula Guerreiro sur Unsplash