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

Historically we have not provided a `FetchEvent.clientId` value for navigation requests.  Both firefox and chrome returned `null` instead.

When `resultingClientId` was spec'd the plan became to start setting this value.  Until that is implemented, though, we chose not to expose `FetchEvent.clientId` in case sites were relying on that to infer navigation requests somehow.

Until that implementation happens, however, we have this WPT check:

https://github.com/w3c/web-platform-tests/blob/master/service-workers/service-worker/resources/clients-get-worker.js#L7

Up until recently this checked that `null` was provided.  It appears @youennf changed this require empty string instead.  As a result both firefox and chrome are timing out all tests using this worker script.

My question is how should we resolve this?  My thoughts:

* We are maintaining null explicitly for backward compat right now.  Of course the spec doesn't say to do this either.
* Nothing in the spec says to explicitly set it to empty string.  Its says to use empty string if not set, but the spec says to override it with a real value when dispatching a FetchEvent.

If there are objections to testing for the historical value of `null` it seems like maybe we should just remove the check from the test.  I don't think we should leave empty string here, though.

@jakearchibald @jungkees @aliams @youennf What do you all think?

-- 
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