Is opt-in required for history-back preemptive transitions?

[bokand]

For regular cross-document VTs, both incoming and outgoing documents must "opt-in" using the @view-transition rule for the transition to be performed. IIUC, this is done primarily for performance reasons (all transitions are same-origin) since VT capture is a fairly heavyweight - the opt-in ensures we don't have to pessimistically capture on every navigation.

The history-back proposal is to use stashed screenshots we preserve on the history entry so the snapshot is ~free. But for consistency it probably makes sense to still require the opt-in on both sides. This would require also stashing the opt-in state of each document that's navigated away.

[khushalsagar]

IIUC, this is done primarily for performance reasons (all transitions are same-origin) since VT capture is a fairly heavyweight

The old Document's opt-in decides whether we capture. We need to capture the old Document before we've parsed the new Document, since we fetch subresources after the navigation commits and the new Document's opt-in could be in one of those sub-resources. I don't think there's a strong reason to check the opt-in on the new Document side, other than maybe it's nice to have a declarative way to opt-out. We assumed that it would be highly unlikely for the opt-in to misalign between 2 same-origin Documents, which is why we optimistically capture the old state.

For the pre-emptive case, using the cached the destination Document's opt-in sounds fine. Unless we want to provide a fallback in case pre-rendering wasn't triggered so we can't possibly know? Seems like its simpler to ignore the new Document's opt-in in this case.