Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support returning ServiceWorker Client environments from Clients.matchAll() #1036

Open
wanderview opened this issue Dec 19, 2016 · 5 comments

Comments

@wanderview
Copy link
Member

Now that we support matching uncontrolled Client environments it seems we should reasonably be able to get a Client object for a ServiceWorker. I believe the spec mostly already supports this as it doesn't explicitly exclude ServiceWorker environments. We just need to add a "serviceworker" enum value to ClientType.

@jakearchibald
Copy link
Contributor

I like the idea of eventually making the clients API available to documents, so yeah, it makes sense to surface service worker clients here.

@wanderview
Copy link
Member Author

Well, this is possible even without window.clients. If you have two service workers registered for the same origin and one does clients.matchAll({ includeUncontrolled: true}) it should in theory include the other service worker as a Client if it happens to be running.

wanderview added a commit to wanderview/ServiceWorker that referenced this issue Feb 15, 2017
This is necessary to allow us to use 'service worker client' to reference
Client objects that are actually backed by a ServiceWorkerGlobalScope
environment.
wanderview added a commit to wanderview/ServiceWorker that referenced this issue Feb 15, 2017
…ceWorkerGlobalScope. Fixes w3c#1036

This adds a "serviceworker" `ClientType` and the associated "service worker
client" object.  It also adds a check to avoid having `clients.matchAll()`
return a `Client` for the current environment.
@jungkees
Copy link
Collaborator

I'll review #1074.

I like the idea of eventually making the clients API available to documents,

That seems like a good direction, but I'm worried the API as-is seems a bit awkward for the case between non-service worker clients. window.clients.get(idOfAnotherWindow).then(client => client.postMessage(msg)); will land on navigator.serviceWorker. This seems to be a separate issue if we would work on that.

@wanderview
Copy link
Member Author

Yes, that is issue #955.

That seems like a good direction, but I'm worried the API as-is seems a bit awkward for the case between non-service worker clients. window.clients.get(idOfAnotherWindow).then(client => client.postMessage(msg)); will land on navigator.serviceWorker. This seems to be a separate issue if we would work on that.

My proposal to fix that is in this comment:

#955 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
@jakearchibald @wanderview @jungkees and others