Clarification: ServiceWorker support/contract for ICoreWebView2CustomSchemeRegistration custom schemes

Aperta
  • Qualcosa non va?
#5,707 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Attiva
Ambito
api, desktop, security, web-dev

Direzione di ricerca

Inizia dalla documentazione di ICoreWebView2CustomSchemeRegistration e dal comportamento di ServiceWorker descritto nell’issue, quindi riproduci l’InvalidStateError con le versioni indicate di Wails, SDK e Runtime. Il lavoro è completato quando un maintainer documenta se gli schemi personalizzati supportano ServiceWorker, se il comportamento è supportato e stabile e se esiste un controllo delle funzionalità supportato.

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

Descrizione

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

Lingua principale
PowerShell
Stelle
526
Fork
70
Merge medio
15g 5h
PR unite (30g)
1

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.