New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clarify when FetchEvent.clientId will or will not be set for navigations #1267
Comments
From an implementation point of view I'm a little uneasy overloading
Its just a bit non-ideal to try to use the same information for policy in one case, but exempt it from that policy in others. But maybe thats an implementation specific concern. |
I kind of like the simplicity of clientId just being empty/null for all navigations. Do we know if people are really asking for a non-empty clientId for these cases? We might just save ourselves time/complexity by sticking with empty/null. The big use case I'm hearing for the new clientId stuff is to implement resultingClientId, so you can track the whole page load (main resource + its subresources). I guess Workers are an interesting point, though. |
I believe its a use case @jakearchibald wants. We'll have to wait from him to surface from holiday to tell us, though. |
I agree the design decision depends on the use cases. Just to clarify, the assumption I had is simply use the request's client for
There should be a source browsing context for this type of navigation requests although the client API won't be able to get a client instance from the
The tab should have a
The responsible browsing context specified by the incumbent settings object.
iframe element's node document's browsing context.
The responsible browsing context specified by entry settings object.
We should define this; it should be the newly created browsing context that the method navigate.
The environment where the Worker constructor is called.
The environment where the Worker constructor called. For the other thoughts:
I think that's rather natural based on the distinction between subresource requests and non-subresource (main resource) requests?
If this is the case, dropping
This seems like the key for decision. |
I don't think we should try to merge the properties back together. They are semantically different and it doesn't cost anything to have two properties. My inclination is to probably implement resultingClientId and keep navigation clientId empty at first. Also note, exposing the clientId on navigations is a bit like referrer restricted to same-origin. It should probably respect the referrer policy. If the policy is set to |
Well, maybe it would be ok for iframes since you can get at the same-origin parent in that case. |
Over in #1266 the question of when exactly
FetchEvent.clientId
will or will not be populated for navigations came up.It seems it must not be populated for:
We could potentially should a clientId for:
Edit: Also:
The text was updated successfully, but these errors were encountered: