On Mon, 5 Oct 2026 20:49:18 GMT, Andy Goryachev <[email protected]> wrote:
>> Marius Hanl has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Simplify the code a little bit
>> - New approach: Reset cssProperties on transitionToState.
>>
>> This fixes basically all weird cases we could have where listeners run
>> during StyleHelper creation to break all our assumptions.
>>
>> transitionToState already handled all cases where css properties must be
>> reset except one: When the property disappeared from the new style map
>> entirely (e.g. changed style class). This is now changed. This makes it
>> actually more CSS spec compliant for transitions and in general, improves
>> the behavior by letting one method do, well the transition.
>> - corner case
>
> modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line
> 227:
>
>> 225: // The css set properties carry over, so those no longer styled
>> are reset when the styles are applied.
>> 226: if (currentHelper != null) {
>> 227:
>> helper.cacheContainer.cssSetProperties.putAll(currentHelper.cacheContainer.cssSetProperties);
>
> we'll have a regression: here we copy old properties (even those removed),
> mixing them with the new.
>
> example:
> 1. style translateX in the stylesheet (.old), style opacity in .new (removing
> translateX)
> 2. applyCss()
> 3. add a listener to translateX which sets opacity
> 4. set style to .new on the root, applyCss()
I had a look and did some research, that seems to be a preexisting issue (kind
of). It is unspecified what happens in this scenario, e.g. which css property
is applied first -> run listener -> change a css property -> the loop may not
even process the change.
This might be another case where it would make sense to first fix this issue on
a seperate branch. I feel like this is an endless story, taking more time than
I have ever had hoped.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/2225#discussion_r4207157837
