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

オープン
  • 何か問題がありますか？
#5,796 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
csharp, web-dev
領域
backend, performance

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
PowerShell
スター
526
フォーク
70
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

MicrosoftEdge/WebView2Feedback のほかの issue

MicrosoftEdge/WebView2Feedback の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。