Drop prefetch/prerender responses without an ok status. #144
Conversation
jeremyroman
changed the title
|
A slightly interesting consequence of this is that this also affects navigations initiated within the prerendering browsing context after the first one. We could not do that if we think it's better, but this is consistent with the versions already there. |
prerendering.bs
Outdated
| @@ -573,6 +576,15 @@ Patch the [=navigate=] algorithm to prevent certain navigations in a [=prerender | |||
|
|
|||
| <p class="issue">Portals might need an extra hook to close the portal in these cases. Or should we reconsider and just do nothing for portals too? That might be more elegant. I think it just requires portals to not be so zealous about clearing the host element/browsing context link, which isn't observable anyway? | |||
|
|
|||
| <div algorithm> | |||
There was a problem hiding this comment.
No need for a new algorithm, this should be incorporated into https://wicg.github.io/nav-speculation/prerendering.html#no-bad-navs
There was a problem hiding this comment.
+1, I think just adding "response does not support prefetch" to that list would be pretty nice and minimal. Although I appreciate the motivation to have a clearly-named "supports prerender" algorithm, all the other stuff in the no-bad-navs section arguably also would belong there...
There was a problem hiding this comment.
Indeed that is the call site of this algorithm. :)
This might be a little preemptive, but my thinking is that this is likely to evolve to also check the resolved value of the Supports-Loading-Mode header etc., and at that time it will be convenient to have this in an algorithm rather than a complicated boolean expression. I'll just inline it for now rather and we can always extract it if that does come to pass.
prerendering.bs
Outdated
| @@ -573,6 +576,15 @@ Patch the [=navigate=] algorithm to prevent certain navigations in a [=prerender | |||
|
|
|||
| <p class="issue">Portals might need an extra hook to close the portal in these cases. Or should we reconsider and just do nothing for portals too? That might be more elegant. I think it just requires portals to not be so zealous about clearing the host element/browsing context link, which isn't observable anyway? | |||
|
|
|||
| <div algorithm> | |||
There was a problem hiding this comment.
+1, I think just adding "response does not support prefetch" to that list would be pretty nice and minimal. Although I appreciate the motivation to have a clearly-named "supports prerender" algorithm, all the other stuff in the no-bad-navs section arguably also would belong there...
Co-authored-by: Domenic Denicola <[email protected]>
No description provided.