1823255 - An element depending on container query units with transitions has an incorrect initial transition

Status: NEW

(Core :: Layout, defect)

Description

[Roman Komarov]

Attachment: Screen Recording 2023-03-19 at 15.29.25.mov

Steps to reproduce:

1. Create a container that has a container-type: size applied to it alongside some dimensions.
2. Add an element inside that depends on that container's dimensions via cqw and/or cqh.
3. Add a transition for those properties.

Example: https://codepen.io/kizu/pen/xxaJoZM — has the transition both when opening the page (for the always-rendered component) and when expanding the <details>.

Actual results:

There is a transition for the element's size from the viewport size to the container's size, with the containment seemingly being applied after the element gets initially rendered, making the containment initiate the transition.

Sometimes the initial size is transitioned from 0, and not from the viewport size (included in an attached video of the bug; not sure if related to the codepen environment)

Expected results:

No transition should happen. Both Chrome and Safari seem to render this fine.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:alaskanemily, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[David Shin[:dshin]]

It does seem related to it being on codepen, at least from my end - can see the element transitioning from zero size more often than not, but with a local copy I cannot seem to get it to do that.

Blink & WebKit seems to just not do that initial transition.

Comment 3

[Roman Komarov]

Attachment: CodePen - Firefox container query units bug.html

I tested on the debug mode, and also by downloading it, and the issue does reproduce for me locally as well, so this is not a codepen-related issue.

I'm attaching the downloaded .html that contains only HTML & CSS from the codepen and which has this transition for me, on Mac OS (13.3), both in Fx 111.0.1 (64-bit) and nightly 113.0a1 (2023-04-10) (64-bit)

Comment 4

[Roman Komarov]

(ah, if this was only about the transition from zero — than it is likely that one is codepen-only, yes)

Comment 5

[mdmoreau]

Just ran into this issue and created a similar codepen: https://codepen.io/mdmoreau/pen/JjQYMWK

Found this bug during a build and ended up having to replace @container with @media in several places to fix things for Firefox. The above demo should show the difference between how @container and @media queries are handled on load, which seems inconsistent. There should be no transition on load (correct in Chrome, Safari) but in Firefox the block using @container transitions on load, while the @media one behaves correctly with no transition.

Codepen debug mode reproduces the bug 100% of the times I've tried, where on occasion an editor view transitions the @media block on load as well. Guessing this is a codepen issue as mentioned above, but locally the behavior matches debug view.

Comment 6

[David Shin[:dshin]]

Attachment: Another Testcase

This has to do with the fact that on the very first style run, we wouldn't have the frames to figure out the container size, so we end up using the viewport size. This happens regardless of transition being specified, it's just that it exposes the issue.

Also, something similar can happen when display: none gets toggled on the closest container , as the new testcase demonstrates - the first transition from viewport size is not new, but when display: none toggles off on .container, the pink .test rectangle transitions from being sized by .parent to being sized by .parent. This does not happen with Blink/WebKit.

Note that when display: none is on .container, it's valid that .test gets contained by .parent, as per this WPT test.

Comment 7

[David Shin[:dshin]]

From discussing this with :emilio a while ago - Sketch of path forward for this:

1. Don't trigger transition for any element until we know we hit the last styling, except if it is previously unstyled.
2. Previously-unstyled elements, on queuing the transition task, sets before_change_style: None.
3. Execution of the transition task, treats before_change_style.is_none() as sentinel to attempt retrieving @starting-style - if not found, transition is not needed.