[css-view-transitions] State management seems broken in the spec

@khushalsagar

Per spec, this snippet calls the transition callback twice:

document.startViewTransition(async function() {
  console.log("cb");
  document.startViewTransition(() => {});
});

This is in fact what happens in Safari TP, and in my experimental Firefox implementation.

Otherwise, set callbackPromise to the result of invoking transition’s update callback.
If transition’s phase is not "done", then set transition’s phase to "update-callback-called".

But that's already too late, because if something (like startViewTransition) skips the transition, the state is not "update-callback-called".

It seems for this specific case, just swapping those two steps should work. But might be worth looking at similar things in the spec.

@noamr

cc @noamr too.

Good catch, I think swapping them should be sufficient, as the previous steps in call the update callback are just setup and don't have any effect.

Yeah at first I was more concerned about this being a general problem, but this is the only place where I found the issue so far.

[css-view-transitions-1] Swap the order between setting the phase and…

I'm fixing this in WebKit with a WPT: WebKit/WebKit#33091

I'm not sure the exact wording of the current spec PR is right though (I commented there already)

Bug 1916311 - [css-view-transitions] Initial pass at DOM API internal…

[view-transitions] Update callback can incorrectly be called multiple…

Bug 1916311 - [css-view-transitions] Initial pass at DOM API internal…

[css-view-transitions-1] Swap the order between setting the phase and…

Bug 1916311 - [css-view-transitions] Initial pass at DOM API internal…

Navigation Menu