[web-animations-1] should an animation be ready if its associated target's document lacks a browsing context?

[graouts]

There is a WPT test added in web-platform-tests/wpt@90f237a which does the following:

promise_test(t => {
  let anim;
  return getXHRDoc(t).then(xhrdoc => {
    const div = xhrdoc.getElementById('test');
    anim = div.animate(null);
    anim.timeline = document.timeline;
    assert_true(anim.pending, 'The animation should be initially pending');
    return waitForAnimationFrames(2);
  }).then(() => {
    // Because the element is in a document without a browsing context, it will
    // not be rendered and hence the user agent will never deem it ready to
    // animate.
    assert_true(anim.pending,
                'The animation should still be pending after replacing'
                + ' the document timeline');
  });
}, 'Replacing the timeline of an animation targetting an element in a'
   + ' document without a browsing context leaves it in the pending state');

At the time of wring, only Firefox passes that test because both Safari and Chrome resolve the ready promise for this element, likely because it is associated with a timeline that is associated with a document with a browsing context.

However, the Web Animations spec does not mention the notion of a browsing context once. This comment in the test:

    // Because the element is in a document without a browsing context, it will
    // not be rendered and hence the user agent will never deem it ready to
    // animate.

… very likely refers to this spec text about being ready:

An animation is ready at the first moment where both of the following conditions are true:

the user agent has completed any setup required to begin the playback of the animation’s associated effect including rendering the first frame of any keyframe effect.

But I think this definition is too vague to infer that an animation targeting an element that is in a document without a browsing context should not be in the ready state. For instance, is an element with display: none able to render its first frame?

I think we need to clarify what impact the availability of a browsing context has on an animation's ready state.

Assigning this to @birtles as the author of this test, also cc'ing @flackr.

[birtles]

@graouts How does the ready promise get resolved without an active timeline?

The second condition for resolving the ready promise is:

• the animation is associated with a timeline that is not inactive.

If I do:

const anim = new Animation(new KeyframeEffect(document.body, { opacity: [0, 1] }, 1000), null);
anim.play();
requestAnimationFrame(() => {
  console.log(anim.pending);
});

The animation (and it's ready promise) should still be pending because there's no active timeline to resolve the start time against.

[graouts]

@graouts How does the ready promise get resolved without an active timeline?

@birtles The test sets an active timeline (document.timeline). I believe it’s the test’s goal to satisfy the active timeline requirement but not the ability to render the first frame.

[birtles]

@birtles The test sets an active timeline (document.timeline). I believe it’s the test’s goal to satisfy the active timeline requirement but not the ability to render the first frame.

Thanks! Sorry, I overlooked that. Yes, you're right. I'll have another look next week.

Somewhat relatedly, for the code sample I gave, I noticed Chrome gives the wrong result but I don't have a Mac in order to check Safari. Do you know what it does there?

[graouts]

Somewhat relatedly, for the code sample I gave, I noticed Chrome gives the wrong result but I don't have a Mac in order to check Safari. Do you know what it does there?

That code sample produces the same result in Chrome Canary (112.0.5568.0), Firefox Nightly (111.0a1, 2023-02-11) and Safari Technology Preview 163 with the animation marked pending (as expected).

[birtles]

That code sample produces the same result in Chrome Canary (112.0.5568.0), Firefox Nightly (111.0a1, 2023-02-11) and Safari Technology Preview 163 with the animation marked pending (as expected).

Oh, you're right. I don't know what the test was I ran but last week I encountered one case where Chrome was resolving the ready Promise while Firefox wasn't.

I had a look at the original issue and I think it comes back to this comment from the original commit: https://hg.mozilla.org/mozilla-central/rev/a9805d5b89d741e7532aa469e15354533204fffa#l2.11

That is, no-one seems to resolve style for elements in documents without a browsing context.

This comes from bug 1370123.