Re: [w3c/ServiceWorker] Until resultingClientId is implemented, what should FetchEvent.clientId be for navigation requests? (#1266)

> In the particular case of clients-get-worker, I'd probably vote to remove the clientId check and just rely on fetch-event.https.html for test coverage.

I addressed your one review comment.  If you approve the WPT PR I can land this fix for now.  I think this is ok since we have fetch-event.https.html coverage as you pointed out.  I'd like to get our WPT coverage turned back ASAP on for the tests effected by this.  I'm in the middle of touching code that effects other things covered by these tests.

> I'm still wondering though if we needed to make the change from null to empty string for client ids.. what did resultingClientId and targetClientId have to do with that decision?

I think its probably an ergonomics thing?  If you can assume the type of the id is always a string perhaps it makes it easier to work with.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1266#issuecomment-361613147