Community
Participate
Working Groups
Created attachment 274815 [details] Java code to replicate the problem Situation: If a node in a tree viewer is expanded but has 0 children (i.e. because the content provider returned "true" for "hasChildren", but "getChildren" returned an empty array), calling collapseToLevel() on the node does not work correctly on Mac OS: Instead of collapsing the tree node, which should also result in the triangle in front of the node to reset back to the "plus" state, the triangle stays as is, and an empty dummy node appears as a child. A second call to collapseToLevel() then works as expected. This seems to be a caused by the combination of the following: - An optimization inside TreeItem#setExpanded that checks whether any change is necessary: if (itemCount == 0 || expanded == getExpanded ()) return; - The way the JFace AbstractTreeViewer deals with the state of not having any children, but still needing to show the plus/triangle, e.g. the handling in optionallyPruneChildren() and updatePlus(), which inserts dummy items. The problem can be reproduced with the attached demo project: 1) Run the Main class as Java application 2) Manually expand the root nodes in the two tree viewers 3) Click the collapseToLevel("root", TreeViewer.ALL_LEVELS) button -> Left tree does not collapse and an empty dummy node appears as child -> Right tree collapses as expected 4) Click the collapseToLevel("root", TreeViewer.ALL_LEVELS) button a 2nd time -> Left tree now also collapses as expected P.S.: Not sure if this is the same or a related issue, but if TreeViewer#setExpandedState("root", false) is called instead (the lower button in the demo), both Windows and MacOS behave strangely and the left tree does not show the triangle/plus again.
Created attachment 274816 [details] Screenshot after collapse attempt
@Till and Lakshmi: Git history says that you did fixes on the macOS specific part of SWT in the past. We want to try to provide a fix for this bug. We haven't understood the issue completely and we don't know if this is a bug in the mac implementation of SWT or a bug in JFace AbstractTreeViewer. Can you help in understanding the issue so that we are able to provide a fix?
(In reply to Matthias Becker from comment #2) > @Till and Lakshmi: Git history says that you did fixes on the macOS specific > part of SWT in the past. > > We want to try to provide a fix for this bug. We haven't understood the > issue completely and we don't know if this is a bug in the mac > implementation of SWT or a bug in JFace AbstractTreeViewer. > > Can you help in understanding the issue so that we are able to provide a fix? Hi, Is this a regression in 4.8, does it work in previous versions? Can you try to create a SWT only snippet, it would simplify debugging the problem? I've not investigated in detail, but I found 1 difference while debugging. When collapseToLevel is clicked 1st time, in TreeItem.setExpanded(), itemCount = 0. When collapseToLevel is clicked 2nd time, in TreeItem.setExpanded(), itemCount = 1. Can you check why? This causes the first call to TreeItem.setExpanded() to return without any changes.
Hi Lakshmi, thanks for your response. We checked for a regression, but this problem also exists in versions before 4.8. Your investigation is the same as ours. Therefore we have the same question as you, why the collapseToLevel function reacts like it reacts currently. We saw the same behavior as you described in your comment, but maybe we didn't described it detailed enough in our first description. In our opinion we could not deliver a short SWT snippet because we think it depends on the combination of SWT and JFace. So maybe we overlook something, do you have any idea what the problem could be? Thanks for your help!
(In reply to Yannic Soethoff from comment #4) > Hi Lakshmi, > > thanks for your response. We checked for a regression, but this problem also > exists in versions before 4.8. > > Your investigation is the same as ours. Therefore we have the same question > as you, why the collapseToLevel function reacts like it reacts currently. > We saw the same behavior as you described in your comment, but maybe we > didn't described it detailed enough in our first description. > > In our opinion we could not deliver a short SWT snippet because we think it > depends on the combination of SWT and JFace. > > So maybe we overlook something, do you have any idea what the problem could > be? > > Thanks for your help! Any progress on this issue?
