1487534 - Implement FetchEvent.replacesClientId the "resulting" clientId (previously dubbed targetClientId)

Status: NEW

(Core :: DOM: Service Workers, enhancement, P2)

Description

[Andrew Sutherland [:asuth] (he/him)]

There is a long and storied history of clientId identifiers on the FetchEvent dealing with the complex realities of navigation/the web platform/about:blank/redirects/etc.  The long and short of it is:
- At TPAC 2017 the winning choice was { clientId, resultingClientId, replacesClientId } per https://github.com/w3c/ServiceWorker/issues/1091#issuecomment-342569083
- https://github.com/w3c/ServiceWorker/issues/1245 covers the legwork related to finalizing that and getting it into the spec
- https://github.com/w3c/ServiceWorker/pull/1333 very recently landed changing thargetClientId to replacesClientId

Gecko-wise, bug 1264177 covers us implementing "resultingClientId" and that will land soon.  This is the next step and with it we should also start exposing clientId on navigation requests (or rather, "non-subresource" requests).

Comment 1

[arpitjindal.87]

Hello!

Any estimation about this issue? I have a project which relies on this feature.

Thanks.
Best regards,
Arpit Jindal

Comment 2

[senthilsct91]

Hi Team,
Is there any implementation in progress? Because,
I'm intercepting all the requests of my application using service work fetch.
My applications built on jsp. So when user do any action on the screen will result in new page.
Example, when user do form submit it will be new jsp page or new url on browser will show the confirmation.
That is almost all of my request are for non-subresource.
And my application opened in more than 2 tabs.
So I really need replacesClientid in order to find where the request coming (from which client)

I tried some workaround fix, but it not fully working. Because user can do any action on any tab.

So I really need this for my application to work on multiple tabs.

Is there any timeline when this work can be started/completed.