[v3/webview2] Audit: transient COM errors in runtime paths exit the process via errorCallback

[leaanthony]

Background

Chromium.errorCallback logs and then calls os.Exit(1). That is appropriate while the WebView2 environment/controller is being created (the app cannot function without it), but chromium.go routes runtime COM errors through the same path — so any transient failure after startup kills the whole application.

This single pattern has now caused three independent crash reports, each fixed individually on the #5568 branch:

• [v3] (*Chromium).Focus race on production startup — #4835 fix has TOCTOU window #5446 — Focus() during controller init → E_INVALIDARG → exit (startup race)
• 崩溃 #4158 — Focus() on a tray-minimised window → E_INVALIDARG → exit (100% reproducible)
• [Windows] Frameless window reports incorrect innerWidth/innerHeight after minimize and restore on high-DPI displays #5544 (verification) — Eval() during a mixed-DPI monitor-crossing drag → RESOURCE_NOT_IN_CORRECT_STATE → exit

Audit of the remaining runtime sites (31 total errorCallback calls)

Defensibly fatal — init path (~20 sites): Embed, environment/controller creation callbacks, controller setup (lines ~172–392). No change proposed.

Disproportionate — runtime paths (~11 sites):

Method	Failure consequence today	Proposed
Resize/GetClientRect	exit during teardown/DPI churn	log + skip frame
Navigate / NavigateToString	exit	return/log error
Init (AddScriptToExecuteOnDocumentCreated)	exit	log
MessageReceived → TryGetWebMessageAsString	a malformed message kills the app	log + drop message
SetBackgroundColour	exit	log
PermissionRequested (GetPermissionKind/PutState)	exit	log + default-deny
AddWebResourceRequestedFilter	exit	log
PutZoomFactor	exit	log

Proposed direction

Once #5568 lands (which establishes the pattern for Focus/Eval), convert the remaining runtime sites to non-fatal logging in a follow-up PR, keeping fatal behaviour only for the init path. Each conversion is mechanical; the audit above is the work list.

Filed from the triage loop so the work list isn't lost — the per-site line numbers are current as of master @ alpha.99.

[midagedev]

One row is missing from the runtime table, and it is the only site in
chromium.go that does not go through errorCallback at all.

The table lists AddWebResourceRequestedFilter — the registration, which does
call e.errorCallback(err) (master chromium.go:737-742). The handler it
registers is a separate site:

func (e *Chromium) WebResourceRequested(sender *ICoreWebView2, args *ICoreWebView2WebResourceRequestedEventArgs) uintptr {
	req, err := args.GetRequest()
	if err != nil {
		log.Fatal(err)      // master chromium.go:727
	}

Three things follow, all from the code as of master f38ae268:

• It is the only log.Fatal in the file (grep -n 'log\.Fatal' returns
  exactly line 727), so it is not covered by "convert the remaining
  errorCallback sites": there is no errorCallback to convert.
• Because it is log.Fatal rather than errorCallback, it bypasses
  SetErrorCallback entirely — an embedder that installs a handler to keep
  its app alive still exits here.
• The handler runs for every request when a filter is registered with
  ("*", COREWEBVIEW2_WEB_RESOURCE_CONTEXT_ALL), so its blast radius is
  larger than the per-feature sites above it, not smaller.

#6006 converts that one line to the shape #5658 already established for
Resize/GetClientRect (comment on why skipping is recoverable, log.Printf
with the [WebView2] prefix, return 0). It is a single-line change plus the
comment, and CI is green on it.

What I cannot claim: how often GetRequest actually fails in the wild. The
failure requires a transient COM error, so I have no reproduction — only the
three structural facts above.