consider exposing self.clients on window and other worker globals

[wanderview]

The Clients and Client interfaces are pretty close to being a generic API for querying and manipulating windows/workers in the browser. Its nicer than things like window.open() though because its designed to be async and is less permissive in what the caller can do.

I think we should consider exposing Clients and Client interfaces on windows and other worker globals. Perhaps as navigator.clients to avoid name collisions.

To do this we would need to specialize the interface for service workers a bit, though:

1. Clients.claim() does not make sense outside of a service worker global.
2. Client.postMessage() currently goes to navigator.serviceWorker.onmessage. This would need to still happen for service worker globals. When used from other globals we would need to fire the event at a different target. Perhaps navigator.clients.onmessage.
3. The behavior of clients.matchAll() only returning controlled Client objects only makes sense for service worker globals. Other globals should probably imply includeUncontrolled:true.

All same-origin restrictions would still apply. I assume we would only support this in secure contexts.

If we think we might want to do this it would be nice to do it sooner rather than later. Over time we will probably have more service worker specific features creep into the API.

[jakearchibald]

I like this idea, and wish we'd done it in the first place. Just need to work out the API details.

[NekR]

Perhaps as navigator.clients to avoid name collisions

I see the reason but it would be at weird because clients is already on Window (though there were problems with it).

[wanderview]

I see the reason but it would be at weird because clients is already on Window (though there were problems with it).

Do you mean window.caches or was there another clients from a different effort?

[NekR]

@wanderview Yes, I meant window.caches. Sorry, typo.

[wanderview]

Client.postMessage() currently goes to navigator.serviceWorker.onmessage. This would need to still happen for service worker globals. When used from other globals we would need to fire the event at a different target. Perhaps navigator.clients.onmessage.

In regards to this item, perhaps we could make the message event fire at navigator.serviceWorker.onmessage first and then bubble to navigator.clients.onmessage. This would make the new clients.onmessage consistently useful while still allowing back-compat with the serviceWorker.onmessage.

[wanderview]

In regards to this item, perhaps we could make the message event fire at navigator.serviceWorker.onmessage first and then bubble to navigator.clients.onmessage. This would make the new clients.onmessage consistently useful while still allowing back-compat with the serviceWorker.onmessage.

A better solution is to fire two separate events navigator.serviceWorker.onmessage and navigator.clients.onmessage.

[jakearchibald]

I don't disagree, but why's it better?

[wanderview]

I don't disagree, but why's it better?

Is this in reference to firing two message events instead of "bubbling" the event?

This came out of talking with @smaug---- and @bzbarsky about it. They suggested it was a safer way to spec it since it prevents an event listener on one target from blocking a listener on the other from getting it. Firing separate message events for each target is just more predictable.