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

NEW
Unassigned

Status

()

enhancement
P2
normal
10 months ago
3 months ago

People

(Reporter: asuth, Unassigned)

Tracking

(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DWS_NEXT)

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).
Priority: -- → P2

Updated

10 months ago
Whiteboard: DWS_NEXT
You need to log in before you can comment on or make changes to this bug.