JDK-8157398 : [TreeTableView] graphic property of TreeItem is still visible after collapsing tree
  • Type: Bug
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8u92
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2016-05-06
  • Updated: 2022-05-16
  • Resolved: 2016-05-31
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 8
8u102Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_92"
Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
To reproduce just launch class below and collapse root tree - you will see that child treeItem graphics are still visible.



REGRESSION.  Last worked in version 8u91

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When you collapse root tree - you should not see graphics that left from child treeItems
ACTUAL -
When you collapse root tree - you can see graphics that left from child treeItems

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.Collection;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
import javafx.application.Application;
import javafx.beans.property.ReadOnlyStringWrapper;
import javafx.scene.Scene;
import javafx.scene.control.TreeItem;
import javafx.scene.control.TreeTableColumn;
import javafx.scene.control.TreeTableView;
import javafx.scene.shape.Rectangle;
import javafx.stage.Stage;

public class Test extends Application {

	public void start(Stage pStage) {
		pStage.setTitle("Test");

		// create tree items
		final TreeItem<String> root = new TreeItem<>("Root Node");
		root.setExpanded(true);
		
		final Collection<TreeItem<String>> children = IntStream.rangeClosed(1, 5)
				.mapToObj(pIdx ->new TreeItem<>("Child Node " + pIdx, new Rectangle(10, 10)))
				.collect(Collectors.toList());

		root.getChildren().addAll(children);
		
		// create  TreeTableView
		final TreeTableView<String> treeTableView = new TreeTableView<>(root);
		final TreeTableColumn<String,String> column = new TreeTableColumn<>("Column");
		column.setCellValueFactory(
				pTreeItem -> new ReadOnlyStringWrapper(pTreeItem.getValue().getValue()));
		treeTableView.getColumns().add(column);
		
		pStage.setScene(new Scene(treeTableView, 300, 450));
		pStage.show();
	}

	public static void main(String[] pArgs) {
		launch(pArgs);
	}
} 
---------- END SOURCE ----------


Comments
Unforunately the regression fix was not applied on OpenJFX-9 while updating one of our applications to OpenJFX-17 we run exactly in this problem who can be reproduced with a slightly modified sample I've attached to this bug. I guess the way forward is to file a new ticket, requesting to apply the isDirty change on OpenJFX-18, right?
22-04-2022

Verifying using PoC: 8u102b01: Graphics are visible after node collapsed. 8u112b01: Graphics are invisible after node collapsed. Verifed.
11-08-2016

UR SQE OK to take the fix to PSU16_03
30-05-2016

Changeset: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/114af16f8e64
26-05-2016

+1
26-05-2016

Webrev available for review at: http://cr.openjdk.java.net/~jgiles/8157398/
25-05-2016

I agree that given the time frame, backing it out seems safest at this point. Please post a webrev with the backout changeset. I'll sanity check it and then it can be pushed to 8u-dev.
25-05-2016

I can reproduce in 8u-dev but not in 9-dev, as Kevin notes. I think the best course of action is to back out the fix for JDK-8143266 from 8u-dev (but leave it in 9-dev as the issue is not present there). This will likely lead to a performance regression, but otherwise looks like a safe course. Will await any feedback.
23-05-2016

I did a quick "hg bisect" and discovered that this regression was caused by the fix for JDK-8143266.
20-05-2016

I can confirm that the test case works in 8u91 and fails in 8u92. This means that some fix that went into 8u92 has caused this regression.
20-05-2016

Note that this not reproducible in JDK 9, so it is likely a duplicate of another bug.
20-05-2016