[css-view-transitions-2] Hold paint of old Document until new Document draws a frame

[khushalsagar]

During a cross-document navigation, there is a duration when the active Document associated with the browsing context (tab) has been swapped. But there is no visual content from the new Document because it hasn't produced a frame yet. The browser has a few options for what to paint during this duration:

1. Keep the last frame from the old Document onscreen. This has security implications if the navigation is cross-origin.
2. Clear the screen immediately and paint any UA defined color.
3. Display cached rendering of the new Document (if available). This is possible for session history navigations where the browser can cache the rendering of a Document when navigating away from it.

View Transitions require 1 since by design we want the new Document to define the transition animations. The new Document starts by displaying images captured from the old Document's last frame. This is done via the pseudo DOM defined here. Until the new Document has produced a frame, the browser needs to paint the last frame from the old Document to avoid visual glitches.

There are also no security implications to this since View Transitions are limited to same-origin.

Proposed Resolution: During a cross-document View Transition, the browser must continue to paint the last frame from the old Document until the new Document produces its first frame.

The behavior for such navigations when there is no View Transition is left to the UA (same as current behaviour).

@smaug---- @noamr

[vmpstr]

What do existing browsers do in cross document navigations to slow pages?

Also, does CSS define any of these concepts like old documents disappearing and new ones appearing? I would've imagined this should go in the html?

[khushalsagar]

What do existing browsers do in cross document navigations to slow pages?

Used https://foil-persistent-bookcase.glitch.me/page2.html for an example of navigation to a slow rendering page. When going to a new Document (same-origin navigation), all browsers are doing option 1 : "Keep the last frame from the old Document onscreen." When going back/forward, Chrome/Firefox do option 3: "Display cached rendering of the new Document" but Safari still does 1.

Also, does CSS define any of these concepts like old documents disappearing and new ones appearing? I would've imagined this should go in the html?

Neither html nor CSS defines what should draw in the tab in the period between the navigation finishing and the new Document preparing its first frame. Since VT is standardizing cross-document transitions, makes sense for it to go in that spec but open to suggestions here.

[css-meeting-bot]

The CSS Working Group just discussed [css-view-transitions-2] Hold paint of old Document until new Document draws a frame, and agreed to the following:

• RESOLVED: Accept the new behavior, put it in VT2

The full IRC log of that discussion

<fantasai> -> https://github.com/w3c/fxtf-drafts/issues/521
<TabAtkins> khush: Exploring cross-document view transitions
<TabAtkins> khush: When navigating from page A to B, there's a period of time where B is still producing its first frame
<TabAtkins> khush: the browser has to decide what to paint in the tab before this
<TabAtkins> khush: Few options. 1) clear the tab to show white, might make sense if it's cross-origin
<TabAtkins> khush: 2) leave page A's pixels until B paints something
<TabAtkins> khush: 3) If you have cached B, show that until B paints real pixels
<TabAtkins> khush: With view transitions, if going from A to B you need A's pixels in the tab until B is ready, to run the animation
<TabAtkins> khush: otherwise you get a flicker during the transition
<TabAtkins> khush: in chrome, we show cached rendering of B if it's available, otherwise leaves A around.
<TabAtkins> khush: Safari always leaves A around
<TabAtkins> khush: We want to standardize on leaving A's pixels until B draws a frame
<TabAtkins> khush: So two parts, first get a resolution here, second where to actually spec this. HTML and CSS neither actually define this behavior.
<Rossen_> q?
<emilio> q+
<Rossen_> ack s
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to suggest leaving in VT
<TabAtkins> TabAtkins: I think HTML is probably the best place for it - it covers nav and timing and such, better than what CSS has.
<TabAtkins> fantasai: I think the oppsoite - specifying in VT, at least fo rnow, is probably a good idea
<TabAtkins> fantasai: We don't care particularly what the browser does when VT aren't active
<TabAtkins> fantasai: but when there *is* a VT, for it to make sense it has to hold the old paint
<TabAtkins> fantasai: So it's a req of *this spec and feature*
<TabAtkins> fantasai: If at some point we need to spec what happens when there isn't a VT, maybe it can move to HTML or somewhere else
<TabAtkins> emilio: So the diff is...
<TabAtkins> emilio: Clarifying that with the first you mean the page is still interactive?
<TabAtkins> khush: Until the browser switches to showing the live B document, all browsers keep it non-interactive
<TabAtkins> khush: Diff is in most cases if you're going from A to B you only have A's rendering to show
<TabAtkins> khush: but if you're going back, from B->A, then forward again, you might have B's cached rendering. Chrome currently shows that when going forward from A->B
<TabAtkins> emilio: when you are flipping display?
<TabAtkins> khush: There are cases where pages do something in pageShow, it's timing-sensitive
<TabAtkins> khush: If the bfcache restore takes more than a single frame you get flicker - show B, then show A, then see animation
<noamr> q+
<TabAtkins> emilio: Okay so if pageShow takes more than a frame to arrive...
<TabAtkins> khush: right, it wasn't uncommon to see pages accidentally run into this
<TabAtkins> emilio: I have the feeling HTML might be the better palce to put this
<Rossen_> ack emilio
<TabAtkins> khush: I think it's clear on the behavior, just not where it is
<TabAtkins> khush: Happy to put it in VT right now and move it to HTML in the future when it's more mature
<Rossen_> ack noamr
<TabAtkins> noamr: For VT2 and MPA stuff, lots will move into HTML or monkeypatch HTML due to nav interaction, so this will be part of that
<TabAtkins> Rossen_: Okay so sounds like it'll move to HTML later
<TabAtkins> fantasai: Sounds like we want it in VT for now and move it later
<TabAtkins> Rossen_: k, so any objections on putting this behavior into VT2?
<TabAtkins> RESOLVED: Accept the new behavior, put it in VT2