On Tue, 21 Jul 2026 11:36:49 GMT, Marius Hanl <[email protected]> wrote:
> > It existed for when CSS metadata changed for a Node (so almost specifically > > to support what `Control` does with its changeable CSS metadata). When > > force slow path is on, it would lookup all defined CSS properties for that > > Node, and add them to the shared cache entry (the shared cache entry is not > > reset for this as many other nodes can be using it) to ensure that all CSS > > properties that should have a value are part of the shared cache entry, > > specifically if the Node's CSS metadata change introduced new CSS > > properties not seen before. > > Ah that makes sense. > > Sounds hacky, as you also described in your ticket. Since the `CssMetadata` > amount can change anytime, calling `transitionToState` again will not detect > new `CssMetadata` - only when `forceSlowPath` is true or the style helper is > newly created before. > > So this new behavior is always more correct. Yeah -- before it was actually trivial to get the CSS system confused... all you had to do is bind a property, and then change to a pseudo class state combination that it hadn't seen before yet. It would create a new cache entry, but would omit the "locked" property. If a sibling later switched to the same pseudo class state combination, it would use the cache entry with the omitted property and incorrectly reset it... That was the first problem I investigated, but it turned out the problem from the ticket was even more complex (but similar in nature). I understand that when the CSS system was designed, they probably made the assumption that getCssMetaData is immutable (and it is in most cases); then when that assumption failed because of controls and skins, a `forceSlowPath` solution was added... ------------- PR Comment: https://git.openjdk.org/jfx/pull/2218#issuecomment-5034089350
