1893320 - Fix the case when updating the container query condition and changing display from none together

Status: NEW

(Core :: CSS Transitions and Animations, defect)

Description

[Boris Chiou [:boris]]

Basically, this is for this case in css/css-transitions/starting-style-size-container.html.
For more specific, if we do these two operations at the same moment:

<div id="container" style="width: 200px">
  <div id="target" style="display: none"></div>
</div>
<style>
  #container { container-type: inline-size; }
  #target {
    transition: background-color ...;
    background-color: lime;
  }
  @container (width > 300px) {
    @starting-style { #target { background-color: white; } }
  }
  @container (width < 300px) {
    @starting-style { #target { background-color: red; } }
  }
</style>
<script>
  ...
  container.style.width = "400px";
  target.style.display = "block";
  assert_equals(getComputedStyle(target).backgroundColor, "rgb(128, 255, 128)", "@starting-style based on the size query evaluation from the same frame");
  ...
</script>

We are still using the old container value (i.e. width: 200px) to evaluate the condition when creating the CSS transitions. I noticed we will trigger a full matching new restyle for the subtree when changing the width of the container, and in the new restyle, we can get the correct container value. However, we create the CSS transitions in the first style change event, instead of the new triggered restyle, and so the transitions uses the incorrect starting style.

This may be a framework issue among CSS transitions and Container query because we do not cancel the existing transitions if the end values are the same (note: starting-style only affects the start value).

• Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of display property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.)
• Method 2: Try to cancel the existing transitions if the start value gets updated. (But this may be very hard because in general we only care about the end value.)
• Method 3: Try to make sure the container query can evaluate the correct value immediately after we got the style attribute change event of container.style.width = "400px";.

And maybe other better ways.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of display property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.)

I think this is the right thing to do.

Comment 2

[Boris Chiou [:boris]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #1)

Method 1: Avoid creating CSS transitions in the first restyle (i.e. the style change event of display property), and create CSS transitions in the 2nd restyle (i.e. the restyle of the subtree triggered from the change of the size of container.)

I think this is the right thing to do.

Thanks. However, do we have any way to know this element will have a 2nd round full matching restyle (no matter it is caused by container query style change or other things)? This are two possible cases:

1. we only a style change event from display:none.
2. we have a style change event from display:none together with a full matching restyle soon.

We probably need to distinguish these two cases, or we also trigger a 2nd round full matching restyle for this given element, for the 1st case (and add a flag to this element, so we know we have to check CSS transitions in the 2nd round because the 2nd round has the same display property value in old_style and new_style.)

Comment 3

[Emilio Cobos Álvarez (:emilio)]

We should scope transition handling outside of this while loop somehow, the UpdateContainerQueryStyles inside the loop is what can trigger multiple restyles in the same flush

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Err that was meant to link to https://searchfox.org/mozilla-central/rev/6121b33709dd80979a6806ff59096a561e348ae8/layout/base/RestyleManager.cpp#3234