Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #182574 +++ According to bug #182574 comment 7, it can happen in certain situations that drag&drop initiates duplicate jobs for getChildren(), where the 2nd query originally canceled the first one. A workaround has been put in place to avoid the visible effects of this, but eventually the duplicate queries should be avoided. I think the scenario could be reproduced by placing a breakpoint in the workaround code in SystemDeferredTreeContentManager v1.3 according to bug #182574 comment 12, and then performing some drag&drop to a filter. When the breakpoint is hit, a dupliate job is being canceled on behalf of the workaround. The root cause for this should be found and eliminated. Perhaps it's multiple views (treeview, tableview) showing the same resources; perhaps it's some oddities in Refresh queries. Perhaps the issue will be resolved due to other fixes at the time this is finally investigated.
Actually, I'd like to see this investigated for 2.0.1 since it might affect our commercial product.
Bug #164118 might also be related to this.
Bug #160420 might be another incarnation of this.
Bulk update target milestone 2.0.1 -> 3.0
Created attachment 135406 [details] patch to not refresh filter twice when handling SYSTEM_REMOTE_RESOURCE_CREATED event Using the steps provided in the defect, I discovered that the filter was being refreshed twice because, in the SystemView handling for SYSTEM_REMOTE_RESOURCE_CREATED, we refresh all filter references that yield the target object before calling refreshRemoteObject() on that target object itself. Since the target object is also a filter reference, we're doing the refresh on it twice.
I've committed the change to cvs.
