You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@hiroshige-g kindly explained to me some issues with the current spec, which are becoming apparent now that Chromium is working on implementing service worker integration.
The issue stems from the fact that we keep responses in the prefetch records, and then allow reuse of them (as of 5d5ebce) using this line:
The problem is that we didn't clone all the relevant state. In particular, the "reserved client", which roughly represents the destination Window/Document the navigation request is going to be used for.
This leads to the following problematic situation. Let's say /A prefetches /B. The user navigates to /B, but document A (and its prefetch cache) stays in bfcache. The user navigates back to /A, restoring from bfcache. Then the user navigates to /B again. Assume our implementation is the sort that allows reuse in the prefetch cache, so it's reusing the same prefetch record for both navigations to /B.
Then what happens is:
The FetchEvent's resultingClientId for the original prefetch is id1
What happens if the web developer calls clients.get(id1) at this point? There's no actual Window represented by id1, so this doesn't make much sense...
The FetchEvent's resultingClientId for the first navigation to /B is id1
After this navigation, now clients.get(id1) kind of makes sense.
The FetchEvent's resultingClientId for the second navigation to /B is id1
But now what does clients.get(id1) mean? Did two separate Windows share a client ID?!
What we should do instead, is expose the empty string to the prefetch FetchEvent (similar to what is done for <link rel=prefetch>), and then expose separate id1 and id2s for the navigation FetchEvents.
To accomplish this, we suggest the strategy that:
The navigation param's reserved environment always be set to a clone of the request's reserved client, with the clone updated to have a new ID.
The resultingClientId value (set here) is masked to the empty string for the prefetch requests, either by detecting that it's a prefetch request, or by marking the original non-clone reserved client in some special way that the service worker spec can detect.
The text was updated successfully, but these errors were encountered:
@hiroshige-g kindly explained to me some issues with the current spec, which are becoming apparent now that Chromium is working on implementing service worker integration.
The issue stems from the fact that we keep responses in the prefetch records, and then allow reuse of them (as of 5d5ebce) using this line:
in create navigation params from a prefetch record
The problem is that we didn't clone all the relevant state. In particular, the "reserved client", which roughly represents the destination Window/Document the navigation request is going to be used for.
This leads to the following problematic situation. Let's say /A prefetches /B. The user navigates to /B, but document A (and its prefetch cache) stays in bfcache. The user navigates back to /A, restoring from bfcache. Then the user navigates to /B again. Assume our implementation is the sort that allows reuse in the prefetch cache, so it's reusing the same prefetch record for both navigations to /B.
Then what happens is:
FetchEvent
'sresultingClientId
for the original prefetch isid1
clients.get(id1)
at this point? There's no actualWindow
represented byid1
, so this doesn't make much sense...FetchEvent
'sresultingClientId
for the first navigation to /B isid1
clients.get(id1)
kind of makes sense.FetchEvent
'sresultingClientId
for the second navigation to /B isid1
clients.get(id1)
mean? Did two separateWindow
s share a client ID?!What we should do instead, is expose the empty string to the prefetch
FetchEvent
(similar to what is done for<link rel=prefetch>
), and then expose separateid1
andid2
s for the navigation FetchEvents.To accomplish this, we suggest the strategy that:
resultingClientId
value (set here) is masked to the empty string for the prefetch requests, either by detecting that it's a prefetch request, or by marking the original non-clone reserved client in some special way that the service worker spec can detect.The text was updated successfully, but these errors were encountered: