Community
Participate
Working Groups
Create a new java project. Open Project Explorer. Create 2 new classes - Test1 and Test2. Close the java code editors. Select Test1.java in the project explorer. Select Test2.java by doing a mouse down only (so Test1.java still appears highlighted) then drag Test2.java into the code editor area ()- Test1.java is displayed. This only occurs in the Project Explorer, the package explorer works fine.
This is a problem only with the CommonNavigator and it's pretty serious. If you click on an element in the tree and drag it, and that element was not previously the selected element, it will end up dropping the previously selected element (even though the drag feedback [at least on Linux] reports that it's dragging the desired element). The problem seems to be caused by the selection caching mechanism in the CommonViewer. It is not reporting the current selection correctly. I verified this by creating a subclass of the CommonNavigator for testing purposes, and overriding the CommonViewer to not use the selection caching. The problem went away. I'm sorry I don't have the time to try and come up with a patch to fix the caching mechanism. I have only verified this problem on Linux, but it makes DnD with the CommonNavigator essentially useless, as you can't predict what's going to happen. I hope this can be fixed in a 3.3.x maintenance release.
Another way to reproduce this (without using the Java stuff) is: 1) Create a folder1. 2) Create file1 (in a folder outside of folder1) 3) Create file2 (in a folder outside of folder1) 4) Mouse down on file1 and drag to folder1 5) bug: file2 (which was previously selected) will go in folder1, not file1 as expected.
Created attachment 89482 [details] Patch for 3.4M5 The problem is the caching mechanism added by bug 144294 had a bug. The DragStart event appears before the SelectionEvent, and inside of the handling of the DragStart event getSelection() was called, getting the old selection. This patch resets the cache on a mouse down which is a pretty big hammer, but should address the problem. (I tested it and it works fine on my Linux machine). This caching mechanism should really not be here, as it's fairly brittle and should be tested on all platforms. ********* Attention: this is a very serious problem with the CommonNavigator on Linux (and possibly other non-Windows systems), rendering it effectively unusable, because the element you think you are dragging is *not* the element you are actually dragging, even though the GUI feedback shows that it is. I strongly recommend the solution to this bug be put in a 3.3.x maintenance release.
Boris, I think you should look at this a little, as it's related to some earlier issues you were involved in. Bugs 144294 and 140032.
See bug 218604 which is a proposal to remove the caching from the CommonViewer.
escalating... McQ, would we want to put a fix for this into 3.3.2 still? Quoting from comment #3: "this is a very serious problem with the CommonNavigator on Linux, rendering it effectively unusable, because the element you think you are dragging is *not* the element you are actually dragging, even though the GUI feedback shows that it is." The problem happens if the element being dragged was not already selected.
Thanks for bringing this to my attention, Boris. It does seem like a relatively nasty bug to me (given the incorrect drag feedback). However, based on conversation with you, it also appears that the bug was introduced in 3.2.1, and wasn't fixed for 3.2.2, 3.3, or 3.3.1, so I can't bring myself to argue that we should crack open 3.3.2 at this late date. Let's do a solid fix for 3.4, and take the time to ensure that there are no performance impacts, or other unexpected consequences. Michael (Elder) you're flagged as the owner for this bug. Have you been tracking what's been going on here?
I agree it's worth fixing for 3.4, and agree with McQ that a fix for 3.2.2 is probably not the best option given how old the issue is. I'll target early next week to review and release the patch.
(In reply to comment #8) > I agree it's worth fixing for 3.4, and agree with McQ that a fix for 3.2.2 is > probably not the best option given how old the issue is. > > I'll target early next week to review and release the patch. > How about let's fix 218604 (reduce the number of calls to getSelection) and just remove the caching mechanism? I can work a patch for that bug. I think that's the cleanest solution, as caching this is problematic.
Boris, can you and Michael (or someone) get this patch in for RC1? This is really important for 3.4. I wanted to do the removal of caching as mentioned in bug 218604, but I think I waited too long for 3.4, I'm still interested in that for 3.5.
Created attachment 98892 [details] Added correct copyright notice to the patch and updated it per HEAD
Tom, +1 for RC1?
Tom, +1?
Eric, +1 for RC1?
+1 (and I agree that the cache should go away in the future)
Created attachment 100016 [details] Revised to call hookControl() per Boris' suggestion
Looks better. Eric, +1?
Hi Erik, sorry to bug you, but please check this today so we can get this in. Thanks.
no prob...+1 (and hookControl looks to be the right place)... I can't really test the patch since it always worked on XP (the selection happens on the mouse down).
Committed (on Francis' behalf) in >20080515. Francis/Boris, I'll leave it to you to manage the defect's state...
Marking as fixed.
*** Bug 226162 has been marked as a duplicate of this bug. ***
