Nous avons récemment annoncé des changements concernant le calendrier d'abandon de Manifest V2. Bien que nous restions fermement engagés envers Manifest V3, nous reconnaissons qu'il y a encore beaucoup de travail de notre part.
- Avant d'annoncer un nouveau calendrier d'abandon, nous avons fini de combler les lacunes prioritaires de la plate-forme et nous avons éliminé les bugs critiques mentionnés sur cette page.
- Nous avons laissé aux développeurs le temps d'élaborer, en leur garantissant au moins six mois entre l'annonce du calendrier et les tests en attente pour supprimer la prise en charge de Manifest V2.
Combler les lacunes de la plate-forme
Nous nous engageons à combler les lacunes suivantes avant d'annoncer le nouveau calendrier d'abandon de Manifest V2:
Les problèmes ont été recueillis en fonction des commentaires de partenaires, des rapports de bugs et des développeurs. Nous poursuivrons nos efforts continus pour améliorer la stabilité et les performances globales de la plate-forme d'extension.
Il n'y a actuellement aucun problème en cours considéré comme une lacune critique de la plate-forme.
Les problèmes suivants ont été résolus récemment:
- Prise en charge de la gestion des fichiers sous ChromeOS en remplacement de
chrome.fileBrowserHandler[Chrome 120]. - Compatibilité avec les scripts utilisateur:autorisez l'enregistrement de scripts de contenu avec du code arbitraire à l'aide de la nouvelle API userScripts [Chrome 120].
- Des messages de notification importants pour les service workers supplémentaires pour certaines opérations qui prennent plus de cinq minutes.
- Ajouté dans Chrome 116 pour
permissions.request(),desktopCapture.chooseDesktopMedia(),identity.launchWebAuthFlow()etmanagement.uninstall(). - Ajouté dans Chrome 118 pour
chrome.debugger
- Ajouté dans Chrome 116 pour
- Augmentez le nombre d'ensembles de règles statiques et activés pour les requêtes net déclaratives (DNR). Les ensembles de règles statiques activés sont passés de 10 à 50, et le nombre total d'ensembles de règles statiques est passé de 50 à 100 [Chrome 120].
- Étendez la fonctionnalité Document hors écran pour accepter d'autres raisons d'utiliser un document hors écran. Ajout de
GEOLOCATIONdans Chrome 116. - Amélioration de la compatibilité avec l'API
chrome.tabCapture[Chrome 116]:- Possibilité d'appeler
getMediaStreamId()depuis un service worker. - Prise en charge de l'obtention d'un
MediaStreamà partir d'un ID de flux dans un document hors écran.
- Possibilité d'appeler
- Prolongation de la durée de vie des service workers lorsque des connexions
WebSocketsont actives [Chrome 116].
Questions fréquentes sur Manifest V3
Q: Prévoyons-nous de prendre en charge les service workers persistants ?
R:L'une des principales raisons de passer des scripts d'arrière-plan aux service workers est que le modèle de programmation basée sur les événements est plus économe en mémoire, car il est é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 tous les appels d'API prolongent la durée de vie du service worker.
- Certains cas d'utilisation, tels que la messagerie native, garderont actifs les service workers des extensions pendant plus de 5 minutes.
Q: Est-il possible d'accéder au DOM dans les service workers ?
R:Nous suivons l'approche adoptée par la plate-forme Web qui consiste à ne pas inclure l'accès DOM aux workers Web (qui comprend les service workers). Pour les cas d'utilisation nécessitant un accès DOM en arrière-plan de la part des service workers, nous avons ajouté la possibilité de déléguer les tâches en arrière-plan à des documents hors écran de courte durée qui fournissent un accès DOM complet.
Q: Est-il possible de prendre en charge le code à distance dans Manifest V3 ?
R:Pour renforcer la sécurité des extensions Chrome, nous continuerons d'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:
- Compatibilité avec
eval()dans les extensions des outils de développement - Compatibilité avec les scripts utilisateur
- Exécuter du code hébergé à distance dans des iFrames en bac à sable
- Fichiers de configuration hébergés à distance qui peuvent être interprétés au moment de l'exécution dans le package d'extension. Toutefois, les chemins d'exécution possibles doivent être prédéterminés.
Q: Mon extension Manifest V2 repose sur webRequestBlocking, qui n'est pas compatible avec Manifest V3. Comment puis-je continuer à proposer la même fonctionnalité dans Manifest V3 ?
R:Nous sommes convaincus que la plupart des cas d'utilisation bloquants des requêtes peuvent être résolus avec la nouvelle API declarativeNetRequest, qui présente l'avantage d'éviter l'impact sur les performances de la communication inter-processus, l'exécution de code sur chaque requête ou la nécessité d'un processus d'extension actif au moment de la requête. Toutefois, pour les cas d'utilisation complexes dans les entreprises (ou les établissements d'enseignement), le blocage dynamique des demandes reste disponible.
Avons-nous oublié quelque chose ? Veuillez nous en informer.