documentUrl and documentOrigin should be just url and origin in runtime.getContexts and be defined for the worker context

[tophf]

Any context, be it a document or a worker, always has an intrinsic URL exposed in its location object, so adding the word document is redundant, inconsequential, and wrong as we can't tell one service worker from another (in Chrome extensions can register multiple service workers for nested paths under the root).

• url and origin should be used instead and workers should be supported as they also have a URL (location.href) and origin (location.origin).
• documentUrl and documentOrigin should be kept as a deprecated alias, its value should remain undefined in a non-document context for compatibility with the existing code.

No changes for documentId which is a synthetic separate concept used in many places in other APIs such as tabs, webRequest, webNavigation.

[xeenon]

We discussed this today at TPAC. Originally we considered the role of content scripts in the design of getContexts. In that scenario, url and origin could become more ambiguous. While we should keep this in mind for future manifest versions as a possible time to rename them, for now, we’ve decided not to make any changes.

[tophf]

Looks like you've ignored this problem:

we can't tell one service worker from another (in Chrome extensions can register multiple service workers for nested paths under the root)

I guess I should open a new issue about that?

[Rob--W]

Looks like you've ignored this problem:

we can't tell one service worker from another (in Chrome extensions can register multiple service workers for nested paths under the root)

I guess I should open a new issue about that?

What is the use case for that?

In extensions, only one extension service worker is supported. I know that the web supports multiple service registrations via the scope option of navigator.serviceWorker.register(), but that is not an intentionally supported API in extensions. In fact, when a Chrome extension does that, the generated service worker is a regular service worker without access to extension APIs. If you really want to interact with this service worker, you can use the standard web platform APIs for that, by calling navigator.serviceWorker.getRegistrations().

Note: Firefox does not allow extensions to register its own service workers. The Service Worker specification specifies that the serviceWorker.register() method should reject registrations when the input URL is not http or https: https://www.w3.org/TR/service-workers/#start-register-algorithm . I cannot find evidence of Chrome's support for this to be intentional.

Since we're in the realm of the regular web platform, you could also compare this with dedicated workers (new Worker(url)) and shared workers (new SharedWorker(url)). These workers do not have extension APIs, and do not appear in runtime.getContexts() either.

[tophf]

The use case is proper support of the existing capabilities as extensions support multiple service workers in Chrome. Such a worker doesn't have access to chrome extensions API, but that doesn't mean it's not a context of this extension.

[tophf]

I cannot find evidence of Chrome's support for this to be intentional.

It is intentional, rdevlin explicitly stated it several times.

[tophf]

dedicated [...] and shared workers [...] do not have extension APIs, and do not appear in runtime.getContexts() either.

Looks like a bug in the design of the API, because these workers are also meaningful contexts of the extension.

[tophf]

OTOH, my mistake is that I use a common technical definition for "context" whereas here it means an API-reachable context.