Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Outre le chargement de contenu distant, le contenu peut également être chargé localement dans WebView2. Il existe plusieurs approches qui peuvent être utilisées pour charger du contenu local dans un contrôle WebView2, notamment :
- Accès à l’URL d’un fichier.
- Navigation vers une chaîne HTML.
- Mappage de noms d’hôtes virtuels.
- Gestion de l’événement
WebResourceRequested.
Contenu détaillé :
- Sélection d’une approche
- Chargement de contenu local en accédant à une URL de fichier
- Chargement de contenu local en accédant à une chaîne HTML
- Chargement de contenu local à l’aide du mappage de noms d’hôtes virtuels
- Chargement du contenu local en gérant l’événement WebResourceRequested
- Voir aussi
Sélection d’une approche
Les différentes façons de charger du contenu local dans un contrôle WebView2 prennent en charge les scénarios suivants :
| Scénario | En accédant à l’URL d’un fichier | En accédant à une chaîne HTML | À l’aide du mappage de noms d’hôtes virtuels | À l’aide de WebResourceRequested |
|---|---|---|---|---|
| API DOM basées sur l’origine | ✔️ Oui | Non ❌ | ✔️ Oui | ✔️ Oui |
| API DOM nécessitant un contexte sécurisé | Non ❌ | Non ❌ | ✔️ Oui | ✔️ Oui |
| Contenu dynamique | Non ❌ | ✔️ Oui | Non ❌ | ✔️ Oui |
| Ressources web supplémentaires | ✔️ Oui | Non ❌ | ✔️ Oui | ✔️ Oui |
| Ressources web supplémentaires résolues dans le processus WebView2 | ✔️ Oui | Non ❌ | ✔️ Oui | Non ❌ |
Ces scénarios sont décrits ci-dessous.
Chargement de contenu local en accédant à une URL de fichier
WebView2 permet de naviguer vers des URL de fichiers, de charger du HTML de base ou un PDF. Il s’agit de l’approche la plus simple et la plus efficace pour charger du contenu local. Cependant, elle est moins souple que les autres approches. Comme dans un navigateur web, les URL de fichier sont limitées dans certaines fonctionnalités :
L’origine du document est unique à son chemin d’accès au fichier. Cela signifie que les API web qui nécessitent une origine telle que
localStorageouindexedDBfonctionneront, mais que les données stockées ne seront pas disponibles pour les autres documents locaux chargés à partir d’autres chemins d’accès de fichier.Certaines API web sont limitées aux URL HTTPS sécurisées uniquement et ne sont pas disponibles pour les documents chargés par les URL de fichier. Cela inclut les API permettant d’acquérir
navigator.mediaDevices.getUserMedia()de la vidéo ou du son,navigator.geolocation.getCurrentPosition()d’accéder à la localisation de l’appareil ouNotification.requestPermission()de demander l’autorisation de l’utilisateur pour afficher des notifications.Pour chaque ressource, le chemin complet doit être spécifié.
Pour autoriser les références à d’autres fichiers locaux à partir des URI de fichier ou pour afficher des fichiers XML avec des transformations XSL appliquées, vous pouvez définir l’argument du
--allow-file-access-from-filesnavigateur. Voir la propriété CoreWebView2EnvironmentOptions.AdditionalBrowserArguments.
Considérations relatives au chargement de contenu local en naviguant vers une URL de fichier
Les URL de fichier se comportent comme dans le navigateur. Par exemple, vous ne pouvez pas faire un XMLHttpRequest (XHR) dans une URL de fichier, car vous ne travaillez pas dans le contexte d’une page web.
Vous devez spécifier le chemin d’accès complet du fichier, pour chaque ressource. Par exemple :
file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html
Ressources cross-origin
Lors de la spécification d’une URL de fichier, l’application accède à un fichier sur le disque, et non à un domaine du réseau. Par conséquent, il n’est pas possible d’utiliser des ressources cross-origin dans le document obtenu.
API DOM basées sur l’origine
Un document chargé via une URL de fichier a une origine unique à son chemin d’accès de fichier, tout comme dans le navigateur. Les API web qui nécessitent une origine telle que localStorage ou indexedDB fonctionneront. Cependant, différents documents chargés à partir d’URL de fichiers différentes ne sont pas considérés comme provenant de la même origine et n’auront pas accès aux mêmes données stockées.
API DOM nécessitant un contexte sécurisé
Certaines API web sont limitées aux URL HTTPS sécurisées uniquement et ne sont pas disponibles pour les documents chargés par les URL de fichier. Cela inclut les API permettant d’acquérir navigator.mediaDevices.getUserMedia() de la vidéo ou du son, navigator.geolocation.getCurrentPosition() d’accéder à la localisation de l’appareil ou Notification.requestPermission() de demander l’autorisation de l’utilisateur pour afficher des notifications. Pour plus d’informations, consultez Contextes sécurisés sur MDN.
Contenu dynamique
Lors du chargement d’un document via une URL de fichier, le contenu du document provient de fichiers statiques sur le disque. Cela signifie qu’il n’est pas possible de modifier dynamiquement ce contenu local. Cela est différent du chargement de documents à partir d’un serveur Web, où chaque réponse peut être générée dynamiquement.
Ressources web supplémentaires
La résolution d’URL relative fonctionne également pour les documents chargés via une URL de fichier. Cela signifie que le document chargé peut avoir des références à des ressources Web supplémentaires telles que des fichiers CSS, des scripts ou des images qui sont également traitées via les URL de fichiers.
Ressources web supplémentaires résolues dans le processus WebView2
Les URL de fichiers sont résolues dans les processus WebView2. Il s’agit d’une option plus rapide que WebResourceRequested, qui se résout dans le thread d’interface utilisateur du processus de l’application hôte.
API pour charger du contenu local en naviguant vers une URL de fichier
Exemple d’URL de fichier
Cette section montre à quoi ressemble une URL de fichier pour un chemin d’accès de fichier de contenu local indépendamment de la plate-forme.
Une application WebView2 doit coder les URL de fichiers locaux à l’aide d’un préfixe et de file:/// barres obliques. Par exemple, pour l’exemple de démonstration à faire, le chemin serait :
file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html
Pour copier le chemin complet avec le préfixe « file » pour un fichier local :
Si vous le souhaitez, clonez le dépôt Demos afin d’avoir une copie locale. Voir Étape 5 : Cloner le dépôt Demos dans Installation de l’extension DevTools pour Visual Studio Code.
Dans Microsoft Edge, appuyez sur Ctrl+O pour ouvrir un fichier. Ouvrez un fichier local
.html, tel que le fichierDemos/demo-to-do/index.htmlcloné localement :C:\Users\username\Documents\GitHub\Demos\demo-to-do\index.htmlLa barre d’adresse n’affiche pas le
file:///préfixe au départ, mais commence par la lettre de lecteur :C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html
Cliquez sur la barre d’adresses, puis appuyez sur la touche Accueil ou appuyez sur Ctrl+A pour sélectionner l’intégralité du chemin d’accès.
L’intégralité du chemin d’accès au fichier, y compris
file:///est copiée dans la mémoire tampon du Presse-papiers, de sorte que vous pouvez coller le chemin complet, y compris lefile:///préfixe :file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html
Voir aussi :
- Demo To Do - page rendue
- Demo To Do - code source
- Étape 5 : Clonez le dépôt Demos dans Installationde l’extension DevTools pour Visual Studio Code.
Exemple d’accès à l’URL d’un fichier
webView.CoreWebView2.Navigate(
"file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html");
Chargement de contenu local en accédant à une chaîne HTML
Une autre méthode de chargement du contenu local est la NavigateToString méthode. Cette approche charge le contenu dans WebView2 directement à partir d’une chaîne. Cela peut être utile si vous empaquetez le contenu via le code de l’application ou si vous souhaitez créer dynamiquement le contenu.
Un autre scénario où la navigation vers une chaîne peut être utile est si vous souhaitez charger du contenu qui n’est pas accessible via une URL. Par exemple, si vous disposez d’une représentation en mémoire d’un document HTML, vous pouvez utiliser la méthode pour charger ce NavigateToString contenu dans le contrôle WebView2. Cela peut être utile si vous souhaitez éviter d’avoir à écrire le contenu dans un fichier ou un serveur avant de le charger dans le contrôle.
Considérations relatives au chargement de contenu local en accédant à une chaîne HTML
La chaîne de contenu HTML transmise à la NavigateToString méthode a une taille limite de 2 Mo. Cette limite de taille peut être facilement dépassée, lorsque la chaîne inclut des ressources supplémentaires incorporées. Si cette limite de taille est dépassée, une erreur est renvoyée : « La valeur n’entre pas dans la plage attendue ».
API DOM basées sur l’origine
Un document chargé à l’aide de la NavigateToString méthode a son emplacement about:blank et son origine réglée sur null. Cela signifie que les API web qui dépendent d’une origine définie, telle que localStorage ou indexedDB, ne peuvent pas être utilisées.
API DOM nécessitant un contexte sécurisé
Certaines API web sont limitées aux URL HTTPS sécurisées uniquement et ne sont pas disponibles pour les documents chargés via la NavigateToString méthode car leur emplacement est réglé sur about:blank. Cela inclut les API permettant d’acquérir navigator.mediaDevices.getUserMedia() de la vidéo ou du son, navigator.geolocation.getCurrentPosition() d’accéder à la localisation de l’appareil ou Notification.requestPermission() de demander l’autorisation de l’utilisateur pour afficher des notifications. Pour plus d’informations, consultez Contextes sécurisés sur MDN.
Contenu dynamique
Lorsque vous chargez du contenu local via la NavigateToString méthode, vous fournissez directement le contenu en tant que paramètre de la méthode. Cela signifie que vous contrôlez le contenu au moment de l’exécution et que vous pouvez le générer dynamiquement si nécessaire.
Ressources web supplémentaires
Le chargement de contenu local à l’aide de cette NavigateToString méthode ne permet pas au document obtenu de référencer des ressources web supplémentaires telles que des fichiers CSS, image ou script. La méthode vous permet uniquement de spécifier le contenu de chaîne du document HTML. Pour référencer des ressources web supplémentaires à partir de votre document HTML, utilisez l’une des autres approches décrites dans cet article ou représentez ces ressources web supplémentaires en ligne dans le document HTML.
Ressources web supplémentaires résolues dans le processus WebView2
NavigateToString Ne prend pas en charge les ressources web supplémentaires, comme mentionné ci-dessus.
API pour charger du contenu local en naviguant vers une chaîne HTML
Exemple de représentation sous forme de chaîne d’une page web
Ce qui suit est la représentation sous la chaîne de la page web Demo To Do . La liste ci-dessous a ajouté un habillage de ligne pour plus de lisibilité. En pratique, ces lignes sont concaténées en une seule ligne longue :
`<html lang="en"><head>\n
<meta charset="UTF-8">\n
<meta name="viewport" content="width=device-width, initial-scale=1.0">\n
<title>TODO app</title>\n
<link rel="stylesheet" href="styles/light-theme.css" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)">\n
<link rel="stylesheet" href="styles/dark-theme.css" media="(prefers-color-scheme: dark)">\n
<link rel="stylesheet" href="styles/base.css">\n
<link rel="stylesheet" href="styles/to-do-styles.css">\n
<link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>📋
</text></svg>">\n
</head>\n\n
<body>\n
<h1>📋 My tasks</h1>\n
<form>\n
<div class="new-task-form" tabindex="0">\n
<label for="new-task">➕ Add a task</label>\n
<input id="new-task" autocomplete="off" type="text" placeholder="Try typing 'Buy milk'" title="Click to start adding a task">\n
<input type="submit" value="➡️">\n
</div>\n
<ul id="tasks"><li class="divider">No tasks defined</li></ul>\n
</form>\n\n \x3Cscript src="to-do.js">\x3C/script>\n \n\n
</body>
</html>`
Pour obtenir la chaîne ci-dessus :
Aller à la démo To-Do.
Cliquez avec le bouton droit sur la page web, puis sélectionnez Inspecter pour ouvrir DevTools.
Dans la console de DevTools, entrez :
document.body.parentElement.outerHTML. La console génère une représentation sous forme de chaîne de la page web :
Exemple de navigation vers une chaîne HTML
// Define htmlString with the string representation of HTML as above.
webView.CoreWebView2.NavigateToString(htmlString);
Chargement de contenu local à l’aide du mappage de noms d’hôtes virtuels
Une autre façon de charger du contenu local dans un contrôle WebView2 consiste à utiliser le mappage de noms d’hôtes virtuels. Cela implique de mapper un nom de domaine local vers un dossier local, de sorte que lorsque le contrôle WebView2 tente de charger une ressource pour ce domaine, il charge le contenu à partir de l’emplacement du dossier local spécifié à la place. L’origine du document sera également le nom d’hôte virtuel.
Cette approche vous permet de spécifier l’accès inter-origines, à l’aide de l’énumération CoreWebView2HostResourceAccessKind .
En raison d’une limitation actuelle, le chargement des fichiers multimédias accessibles à l’aide d’un nom d’hôte virtuel peut être lent.
Considérations relatives au chargement de contenu local à l’aide du mappage de noms d’hôtes virtuels
API DOM basées sur l’origine
Le contenu local chargé via le mappage de nom d’hôte virtuel génère un document ayant une URL HTTP ou HTTPS et une origine correspondante. Cela signifie que les API web qui nécessitent une origine telle que localStorage ou indexedDB fonctionneront et d’autres documents qui appartiennent à la même origine pourront utiliser les données stockées. Pour plus d’informations, consultez la stratégie de même origine sur MDN.
API DOM nécessitant un contexte sécurisé
Certaines API web sont limitées aux URL HTTPS sécurisées uniquement. L’utilisation du mappage de noms d’hôtes virtuels fournit une URL HTTPS pour votre contenu local. Cela signifie que des API permettant d’acquérir navigator.mediaDevices.getUserMedia() de la vidéo ou du son, navigator.geolocation.getCurrentPosition() d’accéder à la localisation de l’appareil ou Notification.requestPermission() de demander l’autorisation de l’utilisateur pour afficher des notifications sont disponibles. Pour plus d’informations, consultez Contextes sécurisés sur MDN.
Contenu dynamique
Lorsque vous chargez du contenu local via un mappage de nom d’hôte virtuel, vous mappez un nom d’hôte virtuel vers un dossier local qui contient des fichiers statiques sur le disque. Cela signifie qu’il n’est pas possible de modifier dynamiquement ce contenu local. Cela est différent du chargement de documents à partir d’un serveur Web, où chaque réponse peut être générée dynamiquement.
Ressources web supplémentaires
Le contenu local chargé via le mappage de noms d’hôtes virtuels a une URL HTTP ou HTTPS qui prend en charge la résolution d’URL relative. Cela signifie que le document chargé peut avoir des références à des ressources Web supplémentaires telles que des fichiers CSS, des scripts ou des images qui sont également servis via le mappage de noms d’hôtes virtuels, à l’exception des cartes sources ; consultez Cartes sources avec mappage de noms d’hôtes virtuels, ci-dessous.
Ressources web supplémentaires résolues dans le processus WebView2
Les URL de nom d’hôte virtuel sont résolues dans les processus WebView2. Il s’agit d’une option plus rapide que WebResourceRequested, qui se résout dans le thread d’interface utilisateur du processus de l’application hôte.
Cartes sources avec mappage de noms d’hôtes virtuels
Les mappages sources sont nécessaires pour déboguer le code source du contenu compilé, notamment :
- JavaScript transpilé, tel que TypeScript ou JavaScript minifié.
- CSS compilé, tel que SASS ou SCSS.
WebView2 ne charge pas les cartes sources référencées par le contenu qui a été chargé à l’aide du mappage de noms d’hôtes virtuels.
Par exemple, supposons que WebView2 se charge main.js via le mappage de noms d’hôtes virtuels. Si main.js fait référence main.js.map en tant que mappage source, main.js.map ne sera pas chargé automatiquement.
Pour utiliser des cartes sources avec le mappage de noms d’hôtes virtuels, générez des cartes sources en ligne lors de la compilation de votre contenu. Les cartes sources en ligne sont intégrées dans le fichier compilé correspondant.
API pour charger du contenu local à l’aide du mappage de noms d’hôtes virtuels
Exemple de mappage de noms d’hôtes virtuels
webView.CoreWebView2.SetVirtualHostNameToFolderMapping("demo",
"C:\Github\Demos\demo-to-do", CoreWebView2HostResourceAccessKind.DenyCors);
webView.CoreWebView2.Navigate("https://demo/index.html");
Chargement du contenu local en gérant l’événement WebResourceRequested
Une autre façon d’héberger du contenu local dans un contrôle WebView2 consiste à vous appuyer sur l’événement WebResourceRequested . Cet événement est déclenché lorsque le contrôle tente de charger une ressource. Vous pouvez utiliser cet événement pour intercepter la demande et fournir le contenu local, comme décrit dans Gestion personnalisée des demandes réseau.
WebResourceRequested Vous permet de personnaliser le comportement du contenu local sur une base par demande. Cela signifie que vous pouvez décider des requêtes à intercepter et à fournir votre propre contenu, et des requêtes permettant au contrôle WebView2 de gérer normalement. Toutefois, la personnalisation du comportement nécessite davantage de code, tel que le mappage d’hôte virtuel, et nécessite une connaissance du protocole HTTP, pour pouvoir construire une réponse appropriée.
Du point de vue de WebView2, la ressource est arrivée via le réseau et WebView2 respecte les en-têtes définis par l’application dans le cadre de la réponse. L’utilisation de l’événement WebResourceRequested est également plus lente que d’autres approches, en raison de la communication et du traitement inter-processus nécessaires pour chaque requête.
Inscription de schéma personnalisé
Si vous souhaitez utiliser un schéma personnalisé pour effectuer la demande de ressource Web qui génère l’événement, consultez Inscription WebResourceRequested de schéma personnalisé dans Vue d’ensemble des API WebView2.
Considérations relatives au chargement du contenu local en gérant l’événement WebResourceRequested
API DOM basées sur l’origine
Le contenu local chargé via WebResourceRequested donne lieu à un document ayant une URL HTTP ou HTTPS et une origine correspondante. Cela signifie que les API web qui nécessitent une origine telle que localStorage ou indexedDB fonctionneront et d’autres documents qui appartiennent à la même origine pourront utiliser les données stockées. Pour plus d’informations, consultez la stratégie de même origine sur MDN.
API DOM nécessitant un contexte sécurisé
Certaines API web sont limitées aux URL HTTPS sécurisées uniquement. L’utilisation WebResourceRequested vous permet de remplacer les demandes de ressources web d’URL HTTPS par votre propre contenu local. Cela signifie que des API permettant d’acquérir navigator.mediaDevices.getUserMedia() de la vidéo ou du son, navigator.geolocation.getCurrentPosition() d’accéder à la localisation de l’appareil ou Notification.requestPermission() de demander l’autorisation de l’utilisateur pour afficher des notifications sont disponibles. Pour plus d’informations, consultez Contextes sécurisés sur MDN.
Contenu dynamique
Lors du chargement de contenu local via WebResourceRequested, vous spécifiez le contenu local à charger dans votre gestionnaire d’événements. Cela signifie que vous contrôlez le contenu au moment de l’exécution et que vous pouvez le générer dynamiquement si nécessaire.
Ressources web supplémentaires
WebResourceRequested modifie le contenu chargé via HTTP ou des URL HTTPS, qui prennent en charge la résolution d’URL relative. Cela signifie que le document résultant peut avoir des références à des ressources Web supplémentaires telles que des fichiers CSS, des scripts ou des fichiers image qui sont également traités via WebResourceRequested, à l’exception des cartes sources ; voir Cartes sources avec l’événementWebResourceRequested, ci-dessous.
Ressources web supplémentaires résolues dans le processus WebView2
Lors du chargement de contenu via une URL de fichier ou un mappage de nom d’hôte virtuel, la résolution se produit dans les processus WebView2. Toutefois, l’événement WebResourceRequested est déclenché sur le thread d’interface utilisateur WebView2 de votre processus d’application hôte, ce qui peut entraîner un chargement plus lent du document résultant.
- WebView2 suspend d’abord le chargement de la page web afin d’attendre que l’événement soit envoyé à votre processus d’application hôte.
- WebView2 attend ensuite que votre thread d’interface utilisateur soit disponible.
- WebView2 attend ensuite que le code de votre application gère l’événement.
Cette opération peut prendre un certain temps. Veillez à limiter les appels aux AddWebResourceRequestedFilter ressources web qui doivent déclencher l’événement WebResourceRequested .
Cartes source avec l’événement WebResourceRequested
Les mappages sources sont nécessaires pour déboguer le code source du contenu compilé, notamment :
- JavaScript transpilé, tel que TypeScript ou JavaScript minifié.
- CSS compilé, tel que SASS ou SCSS.
WebView2 ne charge pas les cartes sources référencées par le contenu qui a été chargé à l’aide de l’événement WebResourceRequested .
Par exemple, supposons que vous chargez main.js votre WebResourceRequested gestionnaire d’événements en définissant la Response propriété .CoreWebView2WebResourceRequestedEventArgs Si main.js fait référence main.js.map comme mappage source :
-
main.js.mapne seront pas chargés automatiquement. - Votre
WebResourceRequestedgestionnaire d’événements ne sera plus appelé pour chargermain.js.map.
Pour utiliser des mappages de sources avec WebResourceRequested, utilisez l’une des approches suivantes :
Générez des cartes de sources en ligne lors de la compilation de votre contenu. Les cartes sources en ligne sont intégrées dans le fichier compilé correspondant.
Ou bien, des mappages de sources distincts en ligne sur le contenu au moment de l’exécution dans votre
WebResourceRequestedgestionnaire d’événements. Utilisez cette approche uniquement si votre système de génération ne prend pas en charge les mappages sources intégrés.
API pour charger le contenu local en gérant l’événement WebResourceRequested
Exemple de gestion de l’événement WebResourceRequested
// Reading of response content stream happens asynchronously, and WebView2 does not
// directly dispose the stream once it read. Therefore, use the following stream
// class, which properly disposes when WebView2 has read all data. For details, see
// [CoreWebView2 does not close stream content](https://github.com/MicrosoftEdge/WebView2Feedback/issues/2513).
class ManagedStream : Stream {
public ManagedStream(Stream s)
{
s_ = s;
}
public override bool CanRead => s_.CanRead;
public override bool CanSeek => s_.CanSeek;
public override bool CanWrite => s_.CanWrite;
public override long Length => s_.Length;
public override long Position { get => s_.Position; set => s_.Position = value; }
public override void Flush()
{
throw new NotImplementedException();
}
public override long Seek(long offset, SeekOrigin origin)
{
return s_.Seek(offset, origin);
}
public override void SetLength(long value)
{
throw new NotImplementedException();
}
public override int Read(byte[] buffer, int offset, int count)
{
int read = 0;
try
{
read = s_.Read(buffer, offset, count);
if (read == 0)
{
s_.Dispose();
}
}
catch
{
s_.Dispose();
throw;
}
return read;
}
public override void Write(byte[] buffer, int offset, int count)
{
throw new NotImplementedException();
}
private Stream s_;
}
webView.CoreWebView2.AddWebResourceRequestedFilter("https://demo/*",
CoreWebView2WebResourceContext.All);
webView.CoreWebView2.WebResourceRequested += delegate (object sender,
CoreWebView2WebResourceRequestedEventArgs args)
{
string assetsFilePath = "C:\\Demo\\" +
args.Request.Uri.Substring("https://demo/*".Length - 1);
try
{
FileStream fs = File.OpenRead(assetsFilePath);
ManagedStream ms = new ManagedStream(fs);
string headers = "";
if (assetsFilePath.EndsWith(".html"))
{
headers = "Content-Type: text/html";
}
else if (assetsFilePath.EndsWith(".jpg"))
{
headers = "Content-Type: image/jpeg";
} else if (assetsFilePath.EndsWith(".png"))
{
headers = "Content-Type: image/png";
}
else if (assetsFilePath.EndsWith(".css"))
{
headers = "Content-Type: text/css";
}
else if (assetsFilePath.EndsWith(".js"))
{
headers = "Content-Type: application/javascript";
}
args.Response = webView.CoreWebView2.Environment.CreateWebResourceResponse(
ms, 200, "OK", headers);
}
catch (Exception)
{
args.Response = webView.CoreWebView2.Environment.CreateWebResourceResponse(
null, 404, "Not found", "");
}
};
Voir aussi
- Gérer le contenu chargé dans WebView2 dans Vue d’ensemble des API WebView2
- Page rendue de démonstration To-Do