Partager via

Gestion des événements liés aux processus dans WebView2

  • Article

WebView2 utilise plusieurs processus pour prendre en charge les contrôles WebView2 dans votre application. Étant donné que ces processus peuvent s’arrêter pendant l’utilisation, WebView2 fournit les CoreWebView2.ProcessFailed événements et CoreWebView2Environment.BrowserProcessExited pour que votre application réagisse à différents scénarios. Utilisez ce document pour apprendre à utiliser ces événements pour réagir lorsque ces scénarios se produisent.

Pour améliorer la fiabilité de votre application WebView2, il est recommandé que votre application gère au moins les événements suivants :

Pour utiliser cet article, nous vous recommandons de lire d’abord Modèle de processus pour les applications WebView2. Pour obtenir la liste des API liées aux processus couvertes par cet article, consultez Gestion des processus dans Vue d’ensemble des fonctionnalités et API WebView2.

Événements pour les processus qui se sont arrêtés ou qui ont échoué

Lorsque vous initialisez un contrôle WebView2, WebView2 s’assure qu’il existe un runtime WebView2 pour alimenter votre contrôle et se connecter à son groupe de processus WebView2. Une fois cette connexion établie, votre contrôle commence à surveiller ces processus et signale les événements suivants afin que votre application puisse réagir en conséquence :

  • Tout échec de processus. Lorsque l’un des processus du runtime WebView2 échoue, CoreWebView2 déclenche l’événement ProcessFailed . Cela peut être dû à un plantage du processus ou à un processus de renderer qui ne répond pas. Utilisez cet événement pour les diagnostics et la récupération après des échecs dans les processus WebView2. Consultez Gérer les incidents de processus et Un processus de rendu du contenu dans le contrôle WebView2 s’est arrêté de manière inattendue, ci-dessous.

  • Le processus du navigateur principal se termine. Si le processus du navigateur principal se termine pour une raison quelconque, le CoreWebView2Environment déclenche l’événement BrowserProcessExited . Utilisez cet événement pour synchroniser les opérations impliquant les ressources et la durée de vie du runtime WebView2, telles que la gestion et les mises à jour des dossiers de données utilisateur . Consultez Gérer le processus de navigateur principal arrêté, ci-dessous.

  • Le processus du navigateur principal se bloque. Lorsque le processus du navigateur principal se bloque, il génère à la fois un ProcessFailed événement et un BrowserProcessExited événement, car le processus du navigateur principal s’est arrêté en raison d’une défaillance.

Collecte des détails de l’échec du processus

L’événement ProcessFailed fournit des informations détaillées sur l’échec du processus signalé. Votre application peut utiliser et collecter des informations à partir des arguments d’événement à des fins de surveillance et de diagnostic, y compris la description du processus (pour les processus utilitaires uniquement) et les informations de trame (pour les processus de renderer uniquement).

Certains échecs de processus peuvent déclencher l’événement ProcessFailed sur différents contrôles WebView2 dans votre application. Vous devez décider de la fréquence de collecte des détails et de la façon de gérer les doublons pour ces cas.

En outre, la plupart des incidents de processus génèrent des vidages dans le dossier de données utilisateur, sous le répertoire retourné par FailureReportFolderPath. Vous pouvez utiliser ces vidages pour comprendre les incidents et fournir des informations supplémentaires lorsque vous contactez l’équipe WebView2.

Gérer les incidents de processus

Lorsqu’un incident se produit dans le runtime WebView2, l’événement ProcessFailed est déclenché pour chaque contrôle WebView2 associé au processus de blocage. L’échec peut ou non être récupérable, et certaines défaillances sont récupérables automatiquement.

Vous pouvez utiliser les propriétés suivantes des arguments d’événement pour identifier l’échec :

  • ProcessFailedKind. Combinaison de l’objectif du processus (par exemple, navigateur, renderer ou GPU) et de l’échec (sortie, absence de réponse). Les processus de renderer sont divisés en renderer principal (RenderProcessExited, RenderProcessUnresponsive) et sous-image renderer (FrameRenderProcessExited).

  • ProcessFailedReason. Indique la catégorie du problème à l’origine de l’échec. Certaines de ces raisons d’échec ne s’appliquent qu’à des types d’échec spécifiques.

Le processus du navigateur principal s’est arrêté de manière inattendue

Tous les contrôles WebView2 de votre application utilisant la même configuration d’environnement recevront l’événement ProcessFailed avec :

  • Type d’échec :BrowserProcessExited .
  • Raison de l’échec : any, sauf Unresponsive et LaunchFailed.

Tous les contrôles WebView2 associés sont fermés et votre application doit gérer la récupération après cet échec. Les contrôles WebView2 doivent être recréés.

Un événement unique BrowserProcessExited est également déclenché à partir du CoreWebview2Environment , mais l’ordre de ces événements n’est pas garanti. Votre application doit coordonner ses gestionnaires d’événements pour ces deux événements lorsque le processus du navigateur se bloque. Consultez Gérer le processus de navigateur principal arrêté, ci-dessous.

Un processus de rendu du contenu dans le contrôle WebView2 s’est arrêté de manière inattendue

Le contenu des trames impactées (main ou subframe) est remplacé par une page d’erreur. Chaque contrôle WebView2 où le contenu est affecté reçoit l’événement ProcessFailed avec :

  • Type d’échec :RenderProcessExited ou FrameRenderProcessExited.
  • Raison de l’échec : any, sauf Unresponsive et ProfileDeleted.

Votre application doit gérer la récupération suite à cet échec. Si l’image principale est impactée (RenderProcessExited), vous pouvez utiliser l’API Reload pour recharger le contenu dans vos contrôles. Vous pouvez Close également recréer les contrôles WebView2.

Si l’image principale n’est pas impactée (FrameRenderProcessExited), votre application peut communiquer avec l’image principale pour récupérer le contenu des images impactées. L’événement ProcessFailed fournit des détails pour les images impactées par le biais de la FrameInfosForFailedProcess propriété .

Le processus GPU s’est arrêté de manière inattendue

Le contenu de vos contrôles WebView2 peut clignoter lorsque le processus est automatiquement recréé. Chaque contrôle WebView2 du groupe de processus WebView2 reçoit l’événement ProcessFailed avec :

  • Type d’échec :GpuProcessExited .
  • Raison de l’échec : any, sauf Unresponsive et ProfileDeleted.

Il s’agit de l’échec de processus WebView2 le plus courant et peut être récupéré automatiquement. Votre application n’a pas besoin de gérer la récupération pour cet événement, mais peut collecter des informations pour comprendre les problèmes persistants, ou s’il existe une cause sous-jacente pour les sorties répétées du processus GPU.

Un processus utilitaire s’est arrêté de manière inattendue

Il peut y avoir des interruptions (par exemple, si le processus utilitaire hébergeait le service audio) les processus nécessaires sont automatiquement recréés. Chaque contrôle WebView2 du groupe de processus WebView2 reçoit l’événement ProcessFailed avec :

  • Type d’échec :UtilityProcessExited .
  • Raison de l’échec : any, sauf Unresponsive et ProfileDeleted.

Cet échec de processus n’est pas fatal et peut être récupéré automatiquement. Votre application n’a pas besoin de gérer la récupération pour cet événement, mais peut collecter des informations pour comprendre les problèmes persistants, y compris le ProcessDescription fourni dans les arguments d’événement.

Tout autre processus s’est arrêté de manière inattendue

La plupart des processus du groupe de processus WebView2 sont associés à tous les contrôles WebView2 qui l’utilisent et sont associés ProcessFailed à chaque contrôle avec :

  • Type d’échec :PpapiBrokerProcessExited, PpapiPluginProcessExited, RenderProcessUnresponsive, SandboxHelperProcessExitedou UnknownProcessExited.
  • Raison de l’échec : any, sauf Unresponsive et ProfileDeleted.

Ces échecs de processus ne sont pas fatals et votre application n’a pas besoin de gérer la récupération pour l’un d’eux, mais peut collecter des informations pour comprendre les problèmes persistants.

Gérer les renderers qui ne répondent pas

Lorsque le processus de renderer pour l’image principale dans un contrôle WebView2 ne répond plus à l’entrée utilisateur, l’événement ProcessFailed est déclenché avec :

  • Type d’échec :RenderProcessUnresponsive .
  • Raison de l’échec :Unresponsive .

L’événement continuera d’être déclenché tant que le processus ne répond pas. L’absence de réponse du processus renderer peut se produire pour les raisons suivantes :

  • Un script de longue durée est en cours d’exécution. Par exemple, le contenu web de votre contrôle WebView2 peut effectuer un XHR synchrone ou être entré dans une boucle infinie. Le rechargement du contrôle WebView2 (en appelant Reload) peut rendre le contrôle réactif à nouveau.

  • Le système est occupé.

Cet événement étant déclenché à plusieurs reprises (par exemple, toutes les 15 secondes), vous devez décider du seuil pour que votre application agisse dessus.

Gérer le processus du navigateur principal a été arrêté

L’événement BrowserProcessExited indique que le processus du navigateur principal a été arrêté et que ses ressources (y compris ses processus enfants) ont été libérées. Cela peut se produire pour les raisons suivantes :

  • Tous les contrôles WebView2 du CoreWebView2Environment ont été fermés. Voici quelques exemples de scénarios d’application :

    • Effacement du dossier de données utilisateur.
    • Mise à jour du runtime WebView2.
    • Redémarrage avec une autre configuration d’environnement.
    • Effacement du cache d’authentification.

  • Le processus du navigateur principal a échoué. Consultez Le processus du navigateur principal s’est arrêté de manière inattendue, ci-dessus.

Cet événement est destiné aux opérations impliquant les ressources Runtime WebView2. Votre application peut utiliser le type de sortie et l’ID de processus des arguments d’événement pour déterminer quand et comment gérer l’événement. Par exemple, vous souhaiterez peut-être coordonner avec vos ProcessFailed gestionnaires d’événements pour empêcher les conditions de concurrence qui pourraient survenir lors d’une tentative de récupération tout en essayant de supprimer le dossier de données utilisateur.

Effacement du dossier de données utilisateur

Votre application doit attendre que le runtime WebView2 ait publié le dossier de données utilisateur avant de pouvoir supprimer son contenu. Après avoir fermé tous les contrôles WebView2, l’événement BrowserProcessExited indique que cela s’est produit et que votre application peut poursuivre l’opération.

Voir aussi :

Mise à jour du runtime WebView2

Pour utiliser la dernière version du runtime WebView2 après une mise à jour, votre application doit fermer tous les contrôles WebView2 et créer un nouveau CoreWebView2Environment. Pour vous assurer que la nouvelle version est utilisée, votre application doit attendre l’événement BrowserProcessExited ; sinon, le processus de navigateur principal peut rester actif lorsque le nouvel environnement est créé et le passage à la nouvelle version échoue.

Redémarrage avec une autre configuration d’environnement

La plupart de la configuration utilisée pour un CoreWebView2Environment est liée à la durée de vie du processus de navigateur principal. Pour apporter des modifications à cette configuration (par exemple, pour la langue), votre application doit fermer les contrôles WebView2 existants et attendre BrowserProcessExited avant de recréer les contrôles ; sinon, l’initialisation des contrôles WebView2 à partir du nouveau CoreWebView2Environment risque d’échouer avec une configuration incompatible.

Effacement du cache d’authentification

Le cache d’authentification stocke la sélection du certificat et les informations d’identification à partir des demandes de certificat client HTTPS.

Le cache d’authentification est lié à la durée de vie du processus de navigateur principal. Par conséquent, pour effacer le cache d’authentification, votre application doit recréer ses contrôles WebView2 à partir d’une nouvelle instance de processus de navigateur principal.

Pour vous assurer qu’une nouvelle instance de processus de navigateur principal est utilisée lors de la recréation des contrôles WebView2, votre application doit attendre l’événement BrowserProcessExited avant de continuer . Sinon, le processus de navigateur principal peut rester actif lorsque les contrôles sont recréés, ce qui conserverait le cache d’authentification au lieu de l’effacer comme prévu.

Voir aussi