Delaying transitions until nested iframes are ready

[khushalsagar]

The purpose of the promise based updateDOM callback is to allow developers to delay the start of transition animations until the new DOM is ready. It's unclear how easy it would be to detect this for nested iframes.

Consider the case where the developer inserts an iframe and then resolves the updateDOM callback. The iframe likely wouldn't have loaded and produced a frame before we start the transition animations on the embedding Document.

The browser could help here by internally delaying the animation phase (within a timeout) until all nested iframes have produced a frame. That's probably ok for same origin iframes but with cross-origin iframes it would be an information leak. The embedding page can measure the time it takes for the iframe to be ready.

@jakearchibald @vmpstr FYI

[jakearchibald]

I don't think we should do anything automatic here.

Ideally, things delayed by network should be prepared before calling createTransition. That's tricky with iframes, but I don't think we should solve it within SET, it should be solved more generally with something like prerender.

[smaug----]

The problem isn't with the network load, but how to ensure the iframe has been painted. At which point would rAF start ticking in the iframe if painting is frozen in the main page?

[khushalsagar]

We could avoid suppressing rAF/lifecycle updates in nested iframes but still keep them from being presented to the user. The motivation to suppress both rAF and visual updates in the Document initiating the transition is so:

• Developers doing rAF driven animations can start their animations on the next rAF after updateDOM resolves.
• The CSS animations, which should have a start time based on when rAF/lifecycle updates resume, are presented in the same frame when these updates resume.

But given that nested iframes are not involved in these animations it would be ok if those still had rAF but not visual updates. That said, I don't think that stil fixes the issue. For the following:

document.createTransition({ updateDOM: () => {
  foo = document.createElement('iframe');
  foo.src = '...';
});

The updateDOM promise resolves in the same task which added the iframe. Even if we didn't pause lifecycle updates, it still wouldn't ensure the nested iframe has painted. So we have to do something browser-side to wait until the iframes have had a change to paint and submit a frame.

[jakearchibald]

@smaug----

The problem isn't with the network load, but how to ensure the iframe has been painted. At which point would rAF start ticking in the iframe if painting is frozen in the main page?

Ah, thanks for the clarification. Do browsers do any particular workarounds here if an iframe is involved in a CSS animation?