Community
Participate
Working Groups
[RC3] Steps: 1. Check out org.eclipse.ui.workbench 2. Open Workbench.java 3. Ctrl-O to open Quick Outline 4. Type "r", note that the field "runEventLoop" is the first match 5. Type "u", note that the field is not shown anymore 6. Type arrow-down key, note that you cannot see the selected entry
any filters enabled?
anything in .log? do you sort?
Nothing in the log. I was using a fresh workspace with just the one project, and I did not change any of the preferences. Should be easy to reproduce. Sorry for the [RC3] it should really be [I20050617-0010]. I just tried older builds. It seems the problem was introduced between N20050503-0010 and M7.
Turn on sorting and the problem goes away. With regards to filtering, only the standard filters are enabled (import declarations, synthetic members).
>I just tried older builds. It seems the problem was introduced between >N20050503-0010 and M7. Did it really work in M7? I so, it must be caused by some change(s) in Platform UI / JFace since we didn't touch that code since January.
It works in N20050503-0010 (the oldest build I have around), but does not work in M7.
We can't reproduce, neither on WindowsXP nor Linux.
Ah, I now see it: it's not filtered but still selected but the tree viewer scrolls fully down for whatever reason. If you manually scroll up you'll see the item selected. This does not happen on Linux-GTK. Either TreeViewer or Tree problem. Moving to Platform UI first.
This is indeed a problem in our code. The bug was introduced by the fix to bug 59037 [Navigator] Package explorer flicker when switching/closing editors. The following code in AbstractTreeViewer.setSelectionToWidget was commented out: if (reveal && newSelection.size() > 0) { showItem((Item) newSelection.get(0)); } by doing that, the boolean "reveal" argument of setSelectionToWidget is not honored. CCing Nick and MVM.
Moving to Nick as he implemented the fix to Bug 59037
Should fix for RC4. The fix is to uncomment the commented-out code (the 3 lines in comment 9). The code was commented out because it is redundant when the selection is already being set in the Tree. SWT guarantees that setting the selection will make it visible. However, in this case AbstractTreeViewer.setSelection detects that the selection is unchanged, and does not set it in the Tree, so the selection is not made visible. The fix is low risk, as this is how it worked before the fix to bug 59037.
Note that the rest of the changes for bug 59037 do not need to be undone. The 3 lines here were commented out as an attempted optimization.
+1 for 3.1 RC4. I would like to see this fixed in 3.1.
to be reviewed June 21
approved please fix for RC4
The check for same selection in TreeViewer.setSelection was added in v1.11 of TreeViewer (by Tod), as part of the fix for bug 42175. With the removal of get/setTopItem from this code in v1.15 (by me), it's unclear whether this check is still needed. In any case, the lower risk fix for 3.1 is to just uncomment the three lines in AbstractTreeViewer.setSelectionToWidget.
Fixed in >N20050621. Fix reviewed by Tod. No performance impact is expected by this change, but we'll check the performance tests in the nightly build anyway.
Verified in N20050622 using Boris' original steps.
