[css-view-transitions-1] Avoid duplicate unhandled rejections

[jakearchibald]

In the current spec, this will cause three unhandled rejections:

const transition = document.startViewTransition(() => {
  throw Error('BOOM');
});

As it will cause transition.updateCallbackDone, transition.ready, and transition.finished to reject with the same error.

This doesn't seem great, as there's only really one error.

Instead, transition.ready and transition.finished should not trigger unhandled rejections if they're rejecting for the same reason as transition.updateCallbackDone.

@fantasai @tabatkins @astearns I think this is small and uncontroversial enough to be an async resolution.

PR: #8454

[jakearchibald]

@domenic we kinda discussed this already, but I want to double check with some specifics of this API.

const transition = document.startViewTransition(async () => {
  // Update DOM somehow
});

• transition.updateCallbackDone - rejects/resolves along with the "Update DOM somehow" callback
• transition.ready - fulfills when the transition is ready to play. Rejects if updateCallbackDone rejects, but may also rejects if the transition cannot start for other reasons.
• transition.finished - fulfills when the end state is reached, which is after the transition animation if one happens. Rejects if updateCallbackDone rejects, since the end state cannot be reached.

The proposal is to mark ready and finished as handled if they're being rejected with the same error as transition.updateCallbackDone.

Does that sound reasonable?

[domenic]

That sounds great to me!

[tabatkins]

I don't understand the mechanics behind unhandled rejections, but your argument makes sense to me from a developer experience perspective.

[jakearchibald]

In case it's useful: https://jakearchibald.com/2023/unhandled-rejections/

But yeah, they're thorny. Thorny thorny thorny.

[tabatkins]

Right, I get them from the user side; I meant I don't understand the mechanics of manipulating them from the spec side. But I trust you're doing it right. ^_^

[jakearchibald]

@tabatkins do you think this needs a resolution? If so, can it be async?

[tabatkins]

Resolutions are only needed if (a) the spec is CR or later and you're making a normative change, and/or (b) if you think the edit might be controversial or could use an explicit request for more eyes on it.

This spec is still young and this seems like a minor and safe change. No need for a resolution.