Community
Participate
Working Groups
The basic issues was that we were using 'hand rolled' display filters to start the drag. On Linux this failed because the eventing is asynchronous but the 'DnDInfo' was always set using the Display methods (i.e. getCursorControl(), getCursorLocation()...). By the time the mouse down event arrived the cursor had already been moved to a location where the element under (likely a part) was not a valid 'draggable' element... Selineo fixed me up with the correct pattern which is to use the 'dragDetect' event instead.
Created attachment 197521 [details] Patch to use DragDetect events to start the drag This patch removes *all* the display filters (a very good thing) and replaces them with a model listener that adds a 'dragDetect' listener to all rendered MPartStack's CTF. While this is cleaner we'll have to revisit this post-4.1 since the 'pure Tracker' approach this patch uses *cannot* support more dynamic DnD operations (like 'hosted' drags...).
Committed in >20110607. Applied the patch. This has been tested but should be verified once the new build comes out...
Marking FIXED.
(In reply to comment #1) > Created attachment 197521 [details] > Patch to use DragDetect events to start the drag This change has caused a regression when trying to split yourself in the shared area, see bug 348720.
