JDK-8276176 : CSS relative -fx-font-size of child causes change of parent dimensions
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8u301
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2021-10-28
  • Updated: 2022-02-11
  • Resolved: 2021-11-01
Related Reports
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
Java 8u301


A DESCRIPTION OF THE PROBLEM :
Hello!

We have serious JavaFX problems with our application since the release of Java 8u301. The problems don't exists in Java 8u291. We suspect that they are related to the fix of JDK-8204568 (Relative CSS-Attributes don't work all time).

We provide the source code below. If you run it with 8u291 and then with 8u301 you will see, that the button/radio button are much bigger in 8u301 while the font size is the same. We expect the the size of the button/radio button to be unchanged. 




---------- BEGIN SOURCE ----------
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.RadioButton;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class Starter extends Application {

    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(final Stage primaryStage) {

        primaryStage.setResizable(true);

        Button button = new Button("Button " + System.getProperty("java.version"));
        RadioButton radioButton = new RadioButton("RadioButton " + System.getProperty("java.version"));

        VBox vbox = new VBox(button, radioButton);
        vbox.getStyleClass().add("container");

        Scene scene = new Scene(vbox);

        scene.getStylesheets().add(getClass().getResource("/styles.css").toExternalForm());

        primaryStage.setScene(scene);

        primaryStage.show();
    }
}

---- styles.css ----
.root {
    -fx-font-size: 12px;
}

.container {
    -fx-spacing: 2em;
    -fx-pref-width: 30em;
    -fx-pref-height: 20em;
}

.button,
.radio-button {
    -fx-min-width: 17em;
    -fx-pref-width: 17em;
    -fx-max-width: 17em;

    -fx-min-height: 3em;
    -fx-pref-height: 3em;
    -fx-max-height: 3em;
}

.button .text,
.radio-button .text{
    -fx-font-size: 1.5em;
}

.radio-button {
    -fx-border-color: red;
}


---------- END SOURCE ----------

FREQUENCY : always



Comments
Hello, We think the current behavior(post JDK-8204568) is a correct and the expectation here relies on a buggy behavior. Accommodating their expectation would need to revert JDK-8204568 fix or change in Button’s skin behavior. Analysis: 1. A Button control is combination of Button itself and its text. 2. Even though Button and it’s Text are two different nodes in SceneGraph, their -fx-font-size property should be treated as one and same. 3. In implementation, it is handled such that: If text’s font size gets changed then Button’s properties get recalculated. 3.1 And if the properties are defined relative to font size (em), then they change with -fx-font-size of text. 3.2 This is an existing behaviour (even before JDK-8204568 was fixed) 3.2.1 Before JDK-8204568, If the sample program is changed to use a fixed font size for <.button .text>, then they will see same issue that they are facing now. Button’s properties get calculated relative to .text font size. .root { -fx-font-size: 12px; } .button { -fx-min-height: 2em; } // -> 2 x 40 = 80 px and NOT 2 x 12. .button .text { -fx-font-size: 40px; } 3.3 JDK-8204568 is a fix for incorrect calculation of -fx-font-size when -fx-font-size itself is provided as relative to em. 3.3.1 Before JDK-8204568, .root { -fx-font-size: 12px; } .button { -fx-min-height: 2em; } // = 2 x 12 = 24 px => Incorrect .button .text { -fx-font-size: 2em; } // 2 x 12 = 24 px 3.3.2 After JDK-8204568, .root { -fx-font-size: 12px; } .button { -fx-min-height: 2em; } // = 2 x 24 = 48 px => Correct, matches with 3.2(existing) , which is an existing behavior .button .text { -fx-font-size: 2em; } // = 2 x 12 = 24 px 4. Attaching a table to describe current behavior [-fx-font-size-button-behavior.png] of how em sized property gets calculated. In all cases, it uniformly uses font-size of text as reference to calculate the properties that are relatively sized.
11-02-2022

Hello! Issue JDK-8276176 was closed because it was assessed as no bug. In the meantime, another comment has arisen that speaks for the existence of a bug. We would therefore ask you to reconsider your decision. We work a lot with relative attributes-values (em) and this issue causes a multiplication of those values. The examples shows that. STEPS TO FOLLOW TO REPRODUCE THE PROBLEM : .root { -fx-font-size:12px; } .button { -fx-min-width: 17em; -fx-pref-width: 17em; -fx-max-width: 17em; -fx-min-height: 2em; /*--> result: 12px * 1,5 * 2 = 36. We expect 24 */ -fx-pref-height: 2em; /* same ... */ -fx-max-height: 2em; /* same ... */ } .button .text { -fx-font-size: 1.5em; } EXPECTED - We expect "-fx-max-height: 2em;" in combination with "-fx-font-size: 1.5em;" to result in 24px ACTUAL - We get 36px as a result of "-fx-max-height: 2em;" in combination with "-fx-font-size: 1.5em;"
24-11-2021

Well I'd say this a bit of an edge case because when looking strictly at the DOM the font-size on the Button-node is still 12px and not 18px, it is 18px only at "Button > Text" (at least this is what the CSS applies on the DOM) I wonder what happens (I have not tested if I'd do the following) .button { -fx-font-size: 12px } .button .text { -fx-font-size: 18px }
22-11-2021

Checked with attached testcase in Windows 10, the button are slightly bigger from 8u301 as compared to 8u291, while the font size is same<attached screenshot for reference> Moving to JDK for further review.
02-11-2021

I can reproduce the reported behavior change with JDK 8u301 and with JavaFX 17. I have not yet detemined whether or not this is a bug. The fix for JDK-8204568 fixed a long-standing bug in the computation of attributes defined using relative CSS sizes. It seems likely that the attached test program was depending on the formerly buggy behavior, but I will update this bug once I am sure.
01-11-2021

I confirm that this is not a bug, but is the expected behavior after the fix for JDK-8204568. The test program for this bug is fairly similar to that of JDK-8204568. Namely, attributes of a Labeled Control are specified relative to the font size, in this case the width and height of the Control are specified in "em"s. Prior to the fix for JDK-8204568, the relative attributes were using the wrong font (the root font in this particular case) as the size from which other relative sizes were derived. This led to unexpected (and in some cases, unpredictable) behavior. After the the fix for JDK-8204568, the relative attributes for a Labeled Control are always relative to the font size used to render that control. I added code to the test program to print out the attributes of the Button, and the ran it against 8u291 and 8u301: 8u291: Button@21404208[styleClass=button]'Button 8.0.291' : Font: Font[name=System Regular, family=System, style=Regular, size=18.0] Pref Height: 36.0 8u301: Button@720cfdbe[styleClass=button]'Button 8.0.301' : Font: Font[name=System Regular, family=System, style=Regular, size=18.0] Pref Height: 54.0 Since the prefHeight of the button is specified as 3em, the behavior in 8u291 was wrong and the current behavior as of 8u301 is correct.
01-11-2021

[~pnarayanaswa] The problem first shows in 8u301 according to the Description. Can you try it with 8u301?
29-10-2021