LabeledSkinBase contains this code in computePrefWidth:
// Fix forRT-39889
double graphicWidth = graphic == null ? 0.0 :
Utils.boundedSize(graphic.prefWidth(-1), graphic.minWidth(-1), graphic.maxWidth(-1));
It calls here (out of the blue) some methods to compute widths for the graphic. However, when using a graphic which has a vertical content bias, calling this with -1 violates the contract of prefWidth (and others). From the docs of prefWidth:
--
Layout code which calls this method should first check the content-bias of the node. If the node has a vertical content-bias, then callers should pass in a height value that the preferred width should be based on. If the node has either a horizontal or null content-bias, then the caller should pass in -1.
--
The result is that the wrong width is computed for the graphic and the button (or whatever is using LabeledSkinBase) will become too wide and leave some empty space that is hard to explain.
Putting the exact same objects in an HBox (a graphic and a label) yields the expected results.
// Fix for
double graphicWidth = graphic == null ? 0.0 :
Utils.boundedSize(graphic.prefWidth(-1), graphic.minWidth(-1), graphic.maxWidth(-1));
It calls here (out of the blue) some methods to compute widths for the graphic. However, when using a graphic which has a vertical content bias, calling this with -1 violates the contract of prefWidth (and others). From the docs of prefWidth:
--
Layout code which calls this method should first check the content-bias of the node. If the node has a vertical content-bias, then callers should pass in a height value that the preferred width should be based on. If the node has either a horizontal or null content-bias, then the caller should pass in -1.
--
The result is that the wrong width is computed for the graphic and the button (or whatever is using LabeledSkinBase) will become too wide and leave some empty space that is hard to explain.
Putting the exact same objects in an HBox (a graphic and a label) yields the expected results.