JDK-8128435 : Edge case for Region.boundedSize policy
  • Type: Bug
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 7-pool
  • Priority: P5
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2011-12-01
  • Updated: 2015-06-17
  • Resolved: 2013-12-11
Related Reports
Blocks :  
JDK-8114225 - A Labeled graphic node bounds can extend outside the bounds of the labeled control
Relates :  
JDK-8128852 - Labeled controls always return computed minHeight
Relates :  
JDK-8123939 - Style -fx-wrap-text worked only when set minWidth to control
Description
The min/max policy for sizing children in Region is enforced with calls like boundedSize(child.prefWidth(h), child.minWidth(h), child.maxWidth(h)).

This policy states that if min > max, then min wins. This makes sense if both min and max are computed, or if both are set explicitly. There is one use case, however, where an application might set an explicit max, but not a min. In this case the max loses out if the computed min is larger, which seems wrong.

I suggest that methods such as Region.computeChildPrefAreaWidth() takes this into account and calls  boundedSize(child.prefWidth(h), child.maxWidth(h), child.maxWidth(h)) IFF (child.getMinWidth() < 0 && child.getMaxWidth() >= 0).

There is a problem in that the getMin/MaxWidth/Height methods are defined in the Control class and is not accessible from Region. Another possibility might be to modify Control.getMinWidth/Height methods to return the max value in this particular case.
Comments
Closing as Won't Fix for the reasons above.
11-12-2013
My opinion is that we shouldn't do this and leave it as-is. The (computed) min size serves as a limit that you cannot cross or else the Node will not be correctly rendered. E.g. all Panes under their minimum size will overflow their bounds as they always keep children at least at their minimum size. I can image some Controls being useless when below their minimum size or may also overflow their layout bounds, which might lead to confusion. The developer should be aware of crossing this limit and the requirement for overriding also minimum width/height in this case is a good thing in my opinion.
11-06-2013
I think my second suggestion makes most sense, as it's easier and solves the problem in one place. I propose the following fix in Control.java: @Override public final double minWidth(double height) { double override = getMinWidth(); - if (override == USE_COMPUTED_SIZE) { - return computeMinWidth(height); - } else if (override == USE_PREF_SIZE) { - return prefWidth(height); + if (override == USE_COMPUTED_SIZE || override == USE_PREF_SIZE) { + double minW = (override == USE_COMPUTED_SIZE) ? computeMinWidth(height) : prefWidth(height); + double overrideMaxW = getMaxWidth(); + if (overrideMaxW >= 0 && minW > overrideMaxW) { + // An explicit max wins over non-explicit min + return overrideMaxW; + } + return minW; } return override; } [...] @Override public final double minHeight(double width) { double override = getMinHeight(); - if (override == USE_COMPUTED_SIZE) { - return computeMinHeight(width); - } else if (override == USE_PREF_SIZE) { - return prefHeight(width); + if (override == USE_COMPUTED_SIZE || override == USE_PREF_SIZE) { + double minH = (override == USE_COMPUTED_SIZE) ? computeMinHeight(width) : prefHeight(width); + double overrideMaxH = getMaxHeight(); + if (overrideMaxH >= 0 && minH > overrideMaxH) { + // An explicit max wins over non-explicit min + return overrideMaxH; + } + return minH; } return override; }
01-12-2011
Run the attached test case RT18309.java. The slider controls the gap between the graphic and the text in the two controls, making the computed minWidth increase with the gap size. Note that when the text is squeezed to its minimum length, showing only a "...", then the control has reached a computed minWidth equal to the explicitly set maxWidth of 150. When the gap increases further, then the minWidth forces the control to grow beyond its maxWidth.
01-12-2011