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

Đang mở
  • Có gì không ổn?
#5,796 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
csharp, web-dev
Lĩnh vực
backend, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
PowerShell
Star
526
Fork
70
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MicrosoftEdge/WebView2Feedback

Tất cả issue của MicrosoftEdge/WebView2Feedback

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.