Fix Project Explorer not refreshing source containers after drag-and-drop move
Fixes eclipse-platform#3525
FYI @ptziegler does this fix the issue you see?
This makes things even worse now:
I also don't think refreshing the UI is the correct solution here. The content provider is simply inconsistent.
As an additional information: This entry shows up in the log while moving the file
!ENTRY org.eclipse.ui.navigator 4 0 2025-11-10 12:40:20.423 !MESSAGE Cannot find navigator content extension (using triggerPoints) for object "<null>" parent path: "P/Project". Check that you have an expression for this object in a navigatorContent triggerPoints or enablement.
Test Results
3 018 files +1 006 3 018 suites +1 006 2h 3m 10s ⏱️ + 43m 50s 8 234 tests ± 0 7 983 ✅ - 2 249 💤 ± 0 2 ❌ +2 23 622 runs +7 874 22 826 ✅ +7 577 794 💤 +295 2 ❌ +2
For more details on these failures, see this check.
Results for commit 1c973354. ± Comparison against base commit 39d028ea.
:recycle: This comment has been updated with latest results.
Hm... so maybe like this?
Hm... so maybe like this?
Still the same issue. I did some more debugging and came across this method here. Which is called twice (on the same viewer instance), once by the JavaNavigatorContentProvider and once by the ResourceExtensionContentProvider, both times with the same elements.
https://github.com/eclipse-platform/eclipse.platform.ui/blob/39d028ea57b25aec286fd8c7c3dda24d0677303b/bundles/org.eclipse.ui.navigator/src/org/eclipse/ui/navigator/CommonViewer.java#L334-L345
The second time, this element obviously no longer exists. So instead a "null" tree item is inserted.
If I use this hack here, the viewer is updated correctly again:
@Override
public void remove(Object... elements) {
var e = new Exception();
var st = e.getStackTrace();
if (st[2].toString().contains("org.eclipse.jdt.")) { //$NON-NLS-1$
return;
}
NavigatorPipelineService pipeDream = (NavigatorPipelineService) contentService
.getPipelineService();
PipelinedShapeModification modification = new PipelinedShapeModification(
null, new ContributorTrackingSet(contentService, elements));
pipeDream.interceptRemove(modification);
super.remove(modification.getChildren().toArray());
}
So it seems we maybe need some kind of asyncExec here...
@laeubi I think this one is obsolete now?