First CreateCoreWebView2ControllerAsync intermittently blocks about 5 s in ProfileNetworkContextService::ConfigureNetworkContextParamsInternal (component updater)

Abierto
  • ¿Algo no está bien?
#5,796 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
csharp, web-dev
Área
backend, performance

Línea de trabajo

Start with the startup trace on the browser main thread at ProfileNetworkContextService::ConfigureNetworkContextParamsInternal; compare a stalled launch with a fast one and inspect the 4.99 s blocking call. Use the provided .NET repro and compare runs with and without --disable-component-update. Done means identifying and addressing the intermittent delay while retaining the required component updater behavior.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happened?

The first CreateCoreWebView2ControllerAsync of a browser process sometimes takes 5.4–7.7 s instead of the usual 0.3–1.7 s. There is nothing in between: a launch is either fast or about 5 s slower. Later controllers in the same process are fast (0.1–0.3 s).

A startup trace (--trace-startup) of a slow launch shows the browser main thread in a single 4.99 s ScopedBlockingCallWithBaseSyncPrimitives on this path:

ProfileImpl::OnPrefsLoaded
 > ProfileImpl::OnLocaleReady
  > BrowserContextDependencyManager::DoCreateBrowserContextServices
   > ProfileNetworkContextService::ConfigureNetworkContextParamsInternal
    > ScopedAllowBaseSyncPrimitivesOutsideBlockingScope
     > ScopedBlockingCallWithBaseSyncPrimitives   (4.99 s)

The constant length suggests a timed wait with a 5 s timeout. The fast launches' traces have no long blocking call there.

It happens on new user data folders and on reused ones. It also happens with no other load on the PC, and when the network is unreachable (a dead --proxy-server). --disable-component-update almost removes it. We can't ship that switch, because our users need the updater's components: revocation lists, SmartScreen data and the tracking-prevention lists.

Measured with the repro below (first controller; a launch counts as stalled at more than 3 s):

Launch Stalled
New user data folder 14 / 35 (40%)
New user data folder, PC otherwise idle 5 / 12
Reused user data folder, later launches 17 / 141 (12%)
Reused folder whose components finished installing (5 min first session) 8 / 29
New folder, unreachable network (dead proxy) 3 / 12
New folder, --disable-component-update 1 / 12
Folder first opened with --disable-component-update, next launch without it 6 / 12

Stalls cluster in time: several launches in a row stall, including on different user data folders. A given folder isn't consistently slow or fast.

The effect on our app: a window shows promptly but stays empty for about 6 s instead of about 1 s. That happens on 4 in 10 first launches and about 1 in 8 later launches.

Importance

Moderate. My app's user experience is affected, but still usable.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

156.0.4314.58

SDK Version

1.0.4258.31

Framework

WinUI3/WinAppSDK. The app hosts controllers in a plain Win32 window; the repro below uses WinForms and shows the same behaviour.

Operating System

Windows 11

OS Version

10.0.26300

Repro steps

  1. Build the program below (.NET 9, net9.0-windows, UseWindowsForms, package Microsoft.Web.WebView2 1.0.4258.31).
  2. Run it about 20 times, each time with a new empty user data folder. Wait for the browser process to exit between runs, so the next run can't attach to it.
  3. Read controllerMs from each run. Roughly a third to a half of runs are about 5 s slower than the rest.
  4. Run it again on one of those folders 20 or more times: about 1 in 8 runs stalls the same way.
  5. Add --disable-component-update as the arguments: the stalls almost disappear.
using System.Diagnostics;
using Microsoft.Web.WebView2.Core;

// argv: userDataFolder [additionalBrowserArguments]
internal static class Repro
{
	[STAThread]
	private static void Main(string[] argv)
	{
		ApplicationConfiguration.Initialize();
		var form = new Form { ShowInTaskbar = false, Size = new Size(800, 600) };
		form.Load += async (_, _) =>
		{
			var options = new CoreWebView2EnvironmentOptions(argv.Length > 1 ? argv[1] : "");
			var environment = await CoreWebView2Environment.CreateAsync(null, argv[0], options);
			var controllerOptions = environment.CreateCoreWebView2ControllerOptions();
			controllerOptions.IsInPrivateModeEnabled = true;
			controllerOptions.ProfileName = "repro";
			var clock = Stopwatch.StartNew();
			var controller = await environment.CreateCoreWebView2ControllerAsync(form.Handle, controllerOptions);
			Console.WriteLine($"controllerMs={clock.ElapsedMilliseconds} browserPid={controller.CoreWebView2.BrowserProcessId}");
			controller.Close();
			form.Close();
		};
		Application.Run(form);
	}
}

To see where the time goes, add --trace-startup --trace-startup-duration=10 --trace-startup-file=<path> and open the trace in ui.perfetto.dev. Look for ConfigureNetworkContextParamsInternal on the browser process's main thread.

Our measurements also used a custom scheme registration and a second, non-InPrivate profile. Neither changes the result: the stall is on the first controller only.

Repros in Edge Browser

Not tested.

Regression

Don't know

Last working version (if regression)

(blank)

Startup traces of a stalled and a fast launch are available on request.

Lenguaje dominante
PowerShell
Estrellas
526
Forks
70
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MicrosoftEdge/WebView2Feedback

Todos los issues de MicrosoftEdge/WebView2Feedback

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.