Problèmes connus lors de la migration vers Manifest V3

Cette page décrit les lacunes de la plate-forme résolues lors de la transition vers le fichier manifeste V3 et répond aux questions fréquentes sur la migration.

Lacunes de la plate-forme résolues

Les fonctionnalités suivantes ont été ajoutées pour résoudre les problèmes de migration courants :

  1. Prise en charge de la gestion des fichiers sur ChromeOS en remplacement de chrome.fileBrowserHandler (Chrome 120).
  2. Compatibilité avec les scripts utilisateur : autorisez l'enregistrement de scripts de contenu avec du code arbitraire grâce à la nouvelle API userScripts (Chrome 120).
  3. Keep-alives de service worker renforcés supplémentaires pour certaines opérations qui durent plus de cinq minutes.
    • Ajouté dans Chrome 116 pour permissions.request(), desktopCapture.chooseDesktopMedia(), identity.launchWebAuthFlow() et management.uninstall().
    • Ajouté dans Chrome 118 pour chrome.debugger.
  4. Augmentez le nombre d'ensembles de règles statiques et activés pour Declarative Net Request (DNR). Le nombre de règles statiques activées est passé de 10 à 50, et le nombre total de règles statiques de 50 à 100 (Chrome 120).
  5. Étendez la fonctionnalité Offscreen document pour prendre en charge davantage de raisons d'utiliser un document hors écran. Ajouté GEOLOCATION dans Chrome 116.
  6. Amélioration de la compatibilité avec l'API chrome.tabCapture (Chrome 116) :
    • Appel de l'assistance getMediaStreamId() à partir d'un service worker.
    • Permet d'obtenir un MediaStream à partir d'un ID de flux dans un document hors écran.
  7. Prolongation de la durée de vie des service workers lorsqu'il existe des WebSocket connexions actives (Chrome 116).

Questions fréquentes sur le fichier manifeste V3

Q : Prévoyez-vous de prendre en charge les service workers persistants ?
R : L'une des principales raisons de migrer des scripts d'arrière-plan vers les service workers est le modèle de programmation événementielle plus économe en mémoire, qui découle de la nature éphémère des service workers. Par conséquent, nous ne prévoyons pas de prendre en charge les service workers persistants. Toutefois, pour répondre aux besoins spécifiques des développeurs d'extensions, nous continuons d'apporter de nombreuses améliorations aux service workers. En particulier :

  • Tous les événements d'extension et les appels d'API prolongent la durée de vie du service worker.
  • Certains cas d'utilisation sélectionnés, tels que la messagerie native, permettent de maintenir les service workers des extensions actifs pendant plus de cinq minutes.

Q : Existe-t-il un moyen d'accéder au DOM dans les service workers ?
R : Nous suivons l'approche de la plate-forme Web qui consiste à ne pas inclure l'accès au DOM dans les Web Workers (y compris les service workers). Pour prendre en charge les cas d'utilisation nécessitant un accès DOM en arrière-plan à partir des service workers, nous avons introduit la possibilité de déléguer le travail en arrière-plan à des documents hors écran de courte durée qui offrent un accès DOM complet.

Q : Sera-t-il possible d'accepter le code à distance dans Manifest V3 ?
R : Pour rendre les extensions Chrome plus sécurisées, nous continuerons à interdire l'exécution de code arbitraire hébergé à distance dans les extensions Chrome. Toutefois, cela ne signifie pas que nous interdisons tous les types d'exécution de code dynamique. Nous acceptons toujours différentes options d'exécution dynamique de code dans les extensions Chrome :

Q : Mon extension Manifest V2 repose sur webRequestBlocking, qui n'est pas compatible avec Manifest V3. Comment continuer à fournir les mêmes fonctionnalités dans Manifest V3 ?
R : Nous sommes convaincus que la plupart des cas d'utilisation de blocage des requêtes peuvent être résolus avec la nouvelle API declarativeNetRequest, qui présente l'avantage supplémentaire d'éviter la surcharge de performances liée à la communication inter-processus, à l'exécution de code à chaque requête ou à la nécessité d'un processus d'extension actif au moment de la requête. Toutefois, le blocage dynamique des requêtes est toujours pris en charge pour les cas d'utilisation complexes en entreprise (ou dans le secteur de l'éducation).

Avons-nous oublié quelque chose ? N'hésitez pas à nous le signaler.