Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 470029

Summary: The initial anchor positions for FXChopBoxAnchor are not computed correctly when using Java 8.
Product: [Tools] GEF Reporter: Matthias Wienand <matthias.wienand>
Component: GEF FXAssignee: Matthias Wienand <matthias.wienand>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 0.1.0   
Target Milestone: 3.10.1 (Mars SR1) M1   
Hardware: All   
OS: All   
Whiteboard:

Description Matthias Wienand CLA 2015-06-12 04:01:13 EDT 
The order in which JavaFX properties are updated changed from Java 7 to Java 8. In Java 7, the "layout-bounds" property of a JavaFX Node is updated before its "bounds-in-local" property. However, in Java 8, the "layout-bounds" property is not yet updated when the "bounds-in-local" property changes.

This leads to an error within FXChopBoxAnchor: A VisualChangeListener is used to listen for visual changes, which is based on changes to the "local-to-scene-transform" and "bounds-in-local" properties. In reaction to such changes, a new anchor position is computed. This computation can depend on the "layout-bounds" property of the respective anchorage. When the "layout-bounds" property is not yet updated, incorrect bounds will be used for the anchor position computation.
Comment 1 Matthias Wienand CLA 2015-06-12 05:53:24 EDT 
In order to fix the problem, we could extend the VisualChangeListener, so that notifications are only send out when all related JavaFX properties are updated, i.e. register listeners for "bounds-in-local", "layout-bounds", and "bounds-in-parent" properties, and only send out the boundsChanged notification when all of these properties are changed.
Comment 2 Matthias Wienand CLA 2015-06-25 07:05:58 EDT 
I added listeners for the "layout-bounds" and "bounds-in-parent" properties (additional to the "bounds-in-local" listener) and delayed sending of visual bounds change notifications until all of these properties are updated. The code is published on the master branch, therefore, I resolve this ticket as fixed for 3.10.1M1.