JDK-8122107 : InspectorPanel: Incorrect handling of some values
  • Type: Bug
  • Component: javafx
  • Sub-Component: tools-scenebuilder
  • Affected Version: 7u6
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2012-07-16
  • Updated: 2015-06-17
  • Resolved: 2012-08-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7u40Fixed
Related Reports
Blocks :  
JDK-8103469 - Handling of incorrect values by the inspector could be improved
Duplicate :  
JDK-8126442 - Negative height or width should be forbidden
Description
To reproduce:
-add button
-set buttons Pref Height to "-Infinity"
-set buttons Min Height to "-Infinity"
Where is content panel? What's wrong with some values like "Width"?(see screenshot if needed)
Comments
SB have added in its metadata a set of constraints on the properties. It means that even if some values are allowed by the JavaFX api, SB reject them if they does not make sense. For instance, opacity can take any double value. But the api interprets it as 0 if the value is <0, or 1 if the value is <1. In this case, SB has a constraint that only allow double values between 0 and 1. To be consistent with this, I've done a full pass on all the properties related to width and height, and added constraints when needed. For instance, for the case of this Jira, new constraints have been added on all the Control width and height properties, to allow only positive values, or -1 (USE_COMPUTED_SIZE), or -Infinity (USE_PREF_SIZE). Note that for later release, DTL-5096 will change this behavior.
03-08-2012
No Release Notes comments needed for this one.
24-07-2012
PM: OK
18-07-2012
RM:OK
18-07-2012
ARCH: Approved. We can decide in 1.1 if we want to prevent setting pref sizes to "-Infinity" - or if we wait for the platform classes to reject that value. JUSTIFICATION: This is a corner case. The user has to enter manually "-Infinity" in the TextField. Moreover, everything can be set right afterwards by entering a new valid value. SUGGESTION: We should defer this to SB 1.1. There are actually two possibility we can envisage: a. in 1.1 reject "-Infinity" in the inspector because "-Infinity"==USE_PREF_SIZE and setting pref size to USE_PREF_SIZE makes no sense. or b. do nothing, and wait for the platform classes to fix their behavior and reject such invalid values (see RT-23446).
17-07-2012
SQE: OK
17-07-2012
DEV: Approved
17-07-2012
About the "Regression" label : this is not a regression. This issue was obviously be hidden during the few days we had DTL-4885, that prevented to enter -Infinity for any property.
16-07-2012
Downgrading as major: this is a corner case, and the tool is still sane if you restore pref height to 'correct' values.
16-07-2012
This is negative use case, tool won't be crashed so we can deffer it and downgrade this as major
16-07-2012
About the question "Where is the Content View ?" : Try the following : - drop a Button - drop another Button on the right of the first one - set the prefHeight to -20 - set the minHeight to USE_PREF_SIZE (= -Infinity) The Button has now a negative size : it is not visible, but SB shows its selection handle. if -20 is replaced by a big negative number, the root AnchorPane is the far that the scrollbar cannot find it... Once again, it is the platform behavior.
16-07-2012
We reflect here the platform behavior. In my opinion we should not change anything, and create a bug against the Fx platform. Anyway this is a corner case use case : unless doing it on purpose, I am not sure any user will fall into this by mistake. SB is not crashing in this case : undoing the change, the tool come back in a correct state.
16-07-2012
If you type 24 or -1 in prefHeight everything comes back as normal (except maybe the orange ring). I don't think this qualifies as a blocker I'd say it's a major at most. To trigger it you have to type "-Infinity" in the pref height field - and who will do that? One thing is true though: -Infinity (USE_PREF_SIZE) is not a valid value for pref height - so the inspector should reject it. It seems that the API accepts negative values for pref height - this is strange - it's possibly a bug in the platform. Should the inspector reject negative value even though the platform accept them? My recommendation is: 1. downgrade this as major. 2. prepare a fix to reject "-Infinity" for pref sizes - as setting pref sizes to USE_PREF_SIZE makes no sense. 3. either fix in RC2 with the fix prepared in 2, or defer to 1.1. Andrey, what's you take - would you agree with that?
16-07-2012