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 to 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 currently. The spec has the new resultingClientId language.
• 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 require empty string here, though, because no shipping browser does that and it also doesn't match the spec.

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