RFR: 8204568: Relative CSS-Attributes don't work all time [v2]

[Ambarish Rapte]

On Tue, 9 Feb 2021 01:33:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ambarish Rapte has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update to recalculate properties when font size changes
>
> This is taking me longer to review than I expected, because I ran into some anomalies while doing some additional testing. There is an unexpected change in behavior for nested panes with relative sizes. We need to understand this change before this is integrated.
> 
> I added a modified version of the original test program to the JBS bug report that creates a scene graph like this, where the root and both parent nodes specify the font size in absolute pixels:
> 
>     Root   // -fx-font-size: 96px
>       P1   // -fx-font-size: 48px
>         P2  // -fx-font-size: 36px
>            L1 (unset), L2 (18px), L3 (0.5em)   // All three had padding and bg radius at 0.5em
> 
> The above scene graph works as expected with the fix, whereas before the fix label L3 had incorrect padding.
> 
> I then added a button to cycle through 4 modes replacing first P2, then P1, then the Root with what would be "equivalent" relative font sizes if the definition of an "em" is its parent's font size. 
> 
>     Root   // -fx-font-size: 96px
>       P1   // -fx-font-size: 48px
>         P2  // -fx-font-size: 0.75em
>            L1 (unset), L2 (18px), L3 (0.5em)   // All three had padding and bg radius at 0.5em
> 
>     Root   // -fx-font-size: 96px
>       P1   // -fx-font-size: 0.5em
>         P2  // -fx-font-size: 0.75em
>            L1 (unset), L2 (18px), L3 (0.5em)   // All three had padding and bg radius at 0.5em
> 
>     Root   // -fx-font-size: 8.0em
>       P1   // -fx-font-size: 0.5em
>         P2  // -fx-font-size: 0.75em
>            L1 (unset), L2 (18px), L3 (0.5em)   // All three had padding and bg radius at 0.5em
> 
> Things start getting unexpected when there is a parent with a relative font size, and the label had a relative font size (e.g., L3 when P2 is relative). When all nodes are relative (the last case), the padding size is completely wrong.
> 
> Btw, I'm not currently worried about the calculation of the font size itself; this fix is intended to be a targeted fix that doesn't change the calculated font size (separately, we could look at that, but it would be much riskier and is out of scope for this bug fix). What I want to make sure is that in all cases, specifying the padding or other sizes in a node in ems will be relative to whatever the calculated font size is.

The cause of wrong behaviour in the scenario that Kevin has mentioned in [previous comment](https://github.com/openjdk/jfx/pull/397#pullrequestreview-586076272) :
The font size property of the Controls that are inherited from class `Labeled` is a shared a property. It is shared with a child `LabeledText` control.
The `Label`'s(inherited from Labeled) css properties are first computed relative to the font size property that was computed for Label. And when the font size is computed for LabeledText, it computes a different font size(which is not same as what was computed for Label).
This results in the behaviour that Label's css properties do not remain relative to its font size.

`-fx-font-size` is a very primary property and changing its behaviour may regress lot of applications. So we decided not to change the above behaviour.
Instead the other option to fix is: recompute the relative sized css properties of Labeled when the font size is changed for LabeledText.

Changes in commit:
1. A method to recalculate relative sized properties when font size changes.
2. Added more tests to verify different combinations of css among parent and child.

Tests are written only using Label control. The issue and its fix can also be observed using other controls inherited from Labeled class.(RadioButton, CheckBox, Button,..)

-------------

PR: https://git.openjdk.java.net/jfx/pull/397