This is due to this test:

test(t => {
  const animation = createDiv(t).animate(null);
  const promise = animation.ready;
  animation.cancel();
  assert_not_equals(animation.ready, promise);
}, 'The ready promise should be replaced when the animation is canceled');

The ready promise is rejected when calling cancel() and there is no code handling that promise's rejection. I suppose we could add:

promise_rejects(t, 'AbortError', promise, 'Cancel should abort ready promise');

Aha, thanks @graouts!

If there are other tests that check that animation.cancel() rejects then just animation.cancel().catch(() => {}) would probably be fine here. But are there?

Oh, sorry, it's not the return value of animation.cancel() that is rejected, it's the animation.ready promise.

@birtles does it sound right to you to make this change?

It sounds right to me, if that helps :). Canceling an animation runs the reset an animation's pending tasks steps, which includes rejecting the ready promise.

I updated the test, I think this closes this issue.

Thanks @graouts, your fix worked!
https://wpt.fyi/results/web-animations/timing-model/animations/canceling-an-animation.html?run_id=306910002&run_id=297330004&run_id=308180006

That's what I like to hear! Next step is to fix this last assertion in Safari.

@birtles does it sound right to you to make this change?

The change seems fine. I'm not sure if I agree with having the test harness error on unhandled Promise rejections, however.

I'm not sure if I agree with having the test harness error on unhandled Promise rejections, however.

This happens here:

As you can see, uncaught exceptions are given the same treatment as unhandled rejections. Both can be disabled with setup({allow_uncaught_exception : true}), which by now is a bit of a misnomer.

Is there something you think should change here?

Is there something you think should change here?

It's a bit odd because it means the test ends up testing more than it should in this case.

I suppose on balance, though, there are probably more tests that benefit from having the unhandled rejection check than those that are complicated by it, so maybe it's fine.

Sounds like you would have preferred the fix I suggested in #18932 (comment)?

I'll leave it to the reviewers of this directory to decide what's best here, but if there is anything we can improve on the infra side please let us know. I filed #19021 about this issue being too hard to understand, with a better message I could have spotted the problem and sent a PR directly.

Sounds like you would have preferred the fix I suggested in #18932 (comment)?

That wouldn't work, cancel() doesn't return a promise, but rather resets the ready promise on the animation.

Maybe there's a setup API we could call instead to suppress the harness error.

Uh, make that just promise.catch(() => {}).

Yeah, that would work. @birtles, would you prefer this over the patch I made with the extra assertion?

Yeah, that would work. @birtles, would you prefer this over the patch I made with the extra assertion?

No, what you have is fine. I was just more concerned about if we have to do this a lot.