Runtime 156.0.4314.42 (23 octobre 2026)

Notes de publication pour Microsoft Edge WebView2 Runtime, date de publication : 23 octobre 2026.

En plus des améliorations suivantes du runtime WebView2, vous pouvez également utiliser les nouvelles fonctionnalités de la plateforme Web à partir de Microsoft Edge 156 ; consultez les notes de publication de la plateforme web Microsoft Edge 156 (22 octobre 2026).

Changement cassant à venir : Suppression de l’indicateur de msAbydosHandwritingAttr navigateur WebView2

À partir de la v159, WebView2 supprimera l’indicateur de navigateur déconseillé msAbydosHandwritingAttr . Après cette modification, le passage msAbydosHandwritingAttr par WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTSles arguments du navigateur basé sur le registre ou CoreWebView2EnvironmentOptions.AdditionalBrowserArguments n’activera plus le comportement attendu.

Passez en revue la configuration de votre application et de votre test, et planifiez en conséquence.

Ce que cela signifie pour votre application

  • Les applications qui ne définissent msAbydosHandwritingAttrpas :

    Aucune action requise.

  • Applications ou outils de test qui définissent l’indicateur msAbydosHandwritingAttr :

    Supprimez l’indicateur et validez les scénarios d’écriture msAbydosHandwritingAttr manuscrite sans celui-ci.

  • Déploiements d’entreprise qui configurent les arguments du navigateur via des variables d’environnement ou des paramètres de registre :

    Supprimez l’indicateur de la msAbydosHandwritingAttr configuration gérée.

En savoir plus

Partager des commentaires

Vous avez une question ou avez rencontré une régression ? Signalez un problème dans le référentiel WebView2Feedback avec votre version d’exécution, votre version de Windows, vos étapes de configuration et de reproduction.

Changement cassant à venir : configuration ACL requise pour les runtimes WebView2 Fixed Version gérés par l’application sur Windows

À partir de la v159, WebView2 renforce le bac à sable du moteur de rendu pour les déploiements de version fixe gérés par les applications. Les applications qui déploient et gèrent un runtime Fixed Version non packagé doivent configurer et conserver les entrées de la liste de contrôle d’accès (ACL) Windows requises dans le dossier d’exécution pendant l’installation, les mises à jour d’exécution et les réparations.

Ces instructions s’appliquent aux déploiements de version fixe gérés par des applications et non empaquetés sur Windows 10 et Windows 11. Les déploiements Evergreen et les dossiers de packages gérés par Windows ne nécessitent pas cette action du programme d’installation.

Ce que cela signifie pour votre application

  • Evergreen Runtime :

    Aucune action ACL requise pour les fichiers d’exécution gérés par Microsoft.

  • Applications empaquetées et emplacements de package gérés par Windows :

    Ne modifiez pas manuellement les listes de contrôle d’accès du dossier de package.

  • Runtime de version fixe non empaqueté et géré par l’application :

    Mettez à jour votre programme d’installation, votre programme de mise à jour et votre flux de réparation pour configurer et vérifier les autorisations requises.

Configuration requise

Exécutez les commandes suivantes à partir d’un contexte de programme d’installation avec élévation de privilèges approprié, en remplaçant {Fixed Version path} par le dossier d’exécution déployé par votre application :

icacls "{Fixed Version path}" /grant *S-1-15-2-2:(OI)(CI)(RX)

icacls "{Fixed Version path}" /grant *S-1-15-2-1:(OI)(CI)(RX)

Ces entrées accordent un accès héritable en lecture et en exécution à TOUS LES PACKAGES D’APPLICATION RESTREINTS et TOUS LES PACKAGES D’APPLICATION. Conservez les autorisations existantes du dossier d’exécution.

Comment se préparer

  1. Ajoutez la configuration ACL aux chemins d’installation, de mise à jour d’exécution et de réparation.

  2. Après chaque opération de déploiement, vérifiez que les deux identités disposent d’un accès en lecture et exécution sur le dossier d’exécution et son contenu.

  3. Exécutez l’application installée en tant qu’utilisateur normal et exercez chaque fonctionnalité WebView2 dont votre application dépend. Le chargement initial d’une page ne suffit pas à lui seul.

  4. Gérer WebView2 process-start ou access-denied les échecs avec un chemin de réparation actionnable.

  5. N’utilisez no-sandbox pas ou un autre commutateur de désactivation du bac à sable comme solution de contournement.

En savoir plus

Partager des commentaires

Vous avez une question ou rencontrez une régression de déploiement ? Signalez un problème dans le référentiel WebView2Feedback avec votre modèle de déploiement, votre chemin d’exécution, vos versions de Windows et d’exécution, les listes de contrôle d’accès résultantes et les étapes de reproduction.

Correctifs de bogue

  • Restriction de la surface de mutation DACL.
  • Correction de l’échec de la tentative d’ouverture de session interactive Windows pour l’utilisateur local actuel.
  • Correction d’un problème où WebResourceRequested les événements des workers du service et des workers partagés n’étaient pas correctement étendus au profil WebView2.
  • Correction de la propagation des clics de la barre de titre de la superposition des contrôles de fenêtre (WCO) vers webcontents.
  • Correction d’une fenêtre d’affichage incorrecte en mode minimal.
  • Correction de la prise en charge de JAWS dans une fenêtre minimale.
  • Correction des téléchargements à soumettre pour l’analyse antivirus sous l’identité de l’application hôte au lieu de celle du runtime partagé.
  • Correction de l’état d’invite Mark-of-the-Web afin qu’elle soit suivie par application hôte plutôt que par runtime WebView2 partagé.
  • Correction d’un blocage de connexion par clé d’accès en raison de la valeur null HWND.

Voir aussi

  • Dernière mise à jour :