Clarification: ServiceWorker support/contract for ICoreWebView2CustomSchemeRegistration custom schemes

Hi Microsoft WebView2 team,

I’m looking for clarification on ServiceWorker behavior for WebView2 custom schemes registered through ICoreWebView2CustomSchemeRegistration.

We have a desktop application using a private custom scheme:

computemesh-ui://app

with a pinned stack approximately as follows:

• Wails 2.15.0
• go-webview2 1.0.22
• WebView2 SDK/interface surface 1.0.3537.50
• WebView2 Runtime 152.0.4191.66

Our custom scheme uses the documented custom-scheme registration capabilities, including authority handling and secure-context treatment where applicable.

What we are observing is that ServiceWorker registration from the custom-scheme document fails with:

InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state.

We understand that Chromium has a separate ServiceWorker-capable scheme registry from secure-context, CORS, and CSP handling, and that schemes normally need explicit ServiceWorker enablement at the embedder level.

What we have not been able to find is an explicit Microsoft contract or documentation statement clarifying whether a WebView2 custom scheme registered through ICoreWebView2CustomSchemeRegistration is ever registered as ServiceWorker-capable internally.

Could you please clarify the following:

1. Does ICoreWebView2CustomSchemeRegistration cause the custom scheme to be registered with Chromium as a ServiceWorker-capable scheme?

2. If not, is ServiceWorker registration expected to remain unsupported for documents loaded from WebView2 custom schemes, even when the scheme is treated as secure?

3. Is the observed error:

   InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state.

   an expected result for ServiceWorker registration from such a custom-scheme document?

4. Does a document using a non-ServiceWorker-capable custom scheme receive an underlying ServiceWorker client/provider context at all, even if no JavaScript-visible controller or registration capability is available?

5. Is there any supported WebView2 API that allows us to determine whether the current custom-scheme document has a ServiceWorker client/provider context, independent of whether a controller is attached?

6. Is this behavior considered a supported contract that applications may rely on, or is it currently only an implementation detail that could change in future WebView2 Runtime releases?

Our application does not require ServiceWorkers. In fact, we intentionally want the private renderer to have no ServiceWorker authority, so we are trying to determine whether the current behavior is something we can rely on as part of our security model, or whether we should treat it as version-specific behavior and requalify it on Runtime upgrades.

We are not asking for a workaround to enable ServiceWorkers. We are specifically trying to understand the supported behavior and security contract for custom-scheme documents.

If useful, I can also provide a minimal reproduction and the exact custom-scheme registration configuration.

Thanks,
Cory

Start with the ICoreWebView2CustomSchemeRegistration documentation and the ServiceWorker behavior described in the issue, then reproduce the InvalidStateError using the listed Wails, SDK, and Runtime versions. Done means a maintainer documents whether custom schemes are ServiceWorker-capable, whether the behavior is supported and stable, and whether a supported capability check exists.