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

Aperta
  • Qualcosa non va?
#5,796 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp, web-dev
Ambito
backend, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
PowerShell
Stelle
526
Fork
70
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MicrosoftEdge/WebView2Feedback

Tutte le issue di MicrosoftEdge/WebView2Feedback

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.