Question: The mention of Service Workers here may raise questions, because Service workers are defined for http(s) URLs only: https://w3c.github.io/ServiceWorker/#start-register-algorithm
(in practice mainly https, http is only supported for edge cases such as localhost).

Chrome (and Firefox's experimental implementation) does not permit extension code to register arbitrary service workers. Instead, the extension framework takes care of registering workers despite the http(s) restrictions.

Should we clarify in a note that extensions cannot register Service workers as usual (i.e. the https restriction), but that browsers may spawn a Service worker associated with a WebExtension origin?

Should we drop the mention of workers entirely from this "window.browser" document, and define the worker behavior in an entirely separate spec/PR?

Thanks for the feedback @Rob--W!

because Service workers are defined for http(s) URLs only: https://w3c.github.io/ServiceWorker/#start-register-algorithm (in practice mainly https, http is only supported for edge cases such as localhost).

I am not sure I follow. The spec in this PR says that if window.browser is defined, then self.browser should be defined on any ServiceWorkerGlobalScope whose origin is a webextension. While the service worker spec is only http(s), the thing that is registered as a background script in Chrome for manifest v3 is
ServiceWorkerGlobalScope.

Chrome (and Firefox's experimental implementation) does not permit extension code to register arbitrary service workers. Instead, the extension framework takes care of registering workers despite the http(s) restrictions.

If they are not permitted, then I don't see the problem? ServiceWorkerGlobalScope is what is created when you have an extension in Chrome/Firefox's-experimental-implementation. Can you explain what you are wanting changed?

Should we clarify in a note that extensions cannot register Service workers as usual (i.e. the https restriction)

While I see the use for that in a broader web extensions specification, as there is no other portion of this document is about registering a service worker, or when it should be registered on window. That seems outside of this document's scope.

Should we drop the mention of workers entirely from this "window.browser" document, and define the worker behavior in an entirely separate spec/PR?

Given the current level of web extension specification, having two essentially identical documents to accomplish the same thing ("globalThis.browser should only be used for web extensions") feels unnecessary.

Thanks for the feedback @Rob--W!

because Service workers are defined for http(s) URLs only: https://w3c.github.io/ServiceWorker/#start-register-algorithm (in practice mainly https, http is only supported for edge cases such as localhost).

I am not sure I follow. The spec in this PR says that if window.browser is defined, then self.browser should be defined on any ServiceWorkerGlobalScope whose origin is a webextension. While the service worker spec is only http(s), the thing that is registered as a background script in Chrome for manifest v3 is
ServiceWorkerGlobalScope.

In the realm of specifications, Service Workers (and thus ServiceWorkerGlobalScope instances) only exist on https schemes (and localhost). Here we specify that ServiceWorkerGlobalScope should have a browser object, for WebExtension origins only. I initially found this inconsistent, because the SW spec doesn't leave room for SW on other schemes, while our spec here implies the existence of an extension origin.

I have now reconciled this inconsistency by observing that "extension origin" could theoretically also involve one of the accepted schemes (even though that doesn't happen in practice - as an example from a far past, Chrome had the concept of Hosted apps where regular websites received extra privileges if a crx file defining the "hosted app" was installed).
We (browser vendors) understand the intent and practical meaning here, and I am fine with not mentioning anything more about SW for now.