Bug 301461 – [css-transitions][css-anchor-position] transitioning an accelerated property to show a popover with anchor positioning yields two transitions, fails to transition again

• Status: NEW
• Component: New Bugs

[Antoine Quint]

Created attachment 477196 [details]
Testcase

This is a bug for one of the issues shown in bug 301070, or perhaps it'll be a duplicate, but there's something fishy going on when using a CSS Transition to show a popover when anchor positioning is involved. The attached test case does the following:

======================

<style>

[popover] {
    transition: opacity 1s ease-in-out;

    position-try: flip-inline;

    &:popover-open {
        display: block;
        opacity: 1;
    }

    @starting-style {
        &:popover-open {
            opacity: 0;
        }
    }
}
</style>

<button type="button" popovertarget="popover">Show popover</button>

<div id="popover" popover>
    <p>Popover</p>
</div>

======================

Clicking the "Show popover" visually has the right behavior but as it turns out the `opacity` transitions run twice, a second transition starting once the first, expected, transition completes.

Another issue is that after dismissing the popover, the transition will not run again.

[Antoine Quint]

Using another accelerated property, such as `translate`, reproduces the issue. Using a non-accelerated property, such as `margin-left`, does not reproduce the issue.

[Antoine Quint]

The reason it does not look like a second transition is running is because it's transitioning from `0.999571919` to `1`. I'm not sure yet why it's picking `0.999571919`, which is clearly an animated value and which should not be considered as a value for considering a transition, over the underlying value, which should be 1.

[Antoine Quint]

We get `oldStyle` in `Style::TreeResolver::createAnimatedElementUpdate()` by calling `resolveStartingStyle()` when the first transition is created. When the second is created, we get it by calling `beforeResolutionStyle()`. Somehow an animated value snuck into what is stored in `m_savedBeforeResolutionStylesForInterleaving`.

[Antoine Quint]

I see that there's some code where `m_savedBeforeResolutionStylesForInterleaving` is populated which is specific to when anchor positioning is involved in `Style:::

        // Ensure that style resolution visits any unresolved anchor-positioned elements.
        if (elementAndState.value->stage < AnchorPositionResolutionStage::Resolved) {
            const_cast<Element&>(*elementAndState.key.first).invalidateForResumingAnchorPositionedElementResolution();
            m_needsInterleavedLayout = true;
            saveBeforeResolutionStyleForInterleaving(*elementAndState.key.first);
        }

I get a hunch that is something is wrong either in what we store in `m_savedBeforeResolutionStylesForInterleaving` or the circumstance under which we use it.

[Antoine Quint]

Yes, logging indicates the `oldStyle` we get for the second transition is read from `m_savedBeforeResolutionStylesForInterleaving` and was stored in the function call above. Somehow we're resolving an animated style there, which is incorrect.

[Antoine Quint]

Created attachment 477199 [details]
Testcase

[Radar WebKit Bug Importer]

<rdar://problem/163512045>