Community
Participate
Working Groups
Created attachment 240146 [details] The standalone snippet to reproduce the issue Hi, I have found an issue with SWT_AWT bridge, when drag and dropping from a SWT component to a AWT component, on MacOS X and Java 1.7. The AWT drop target reacts like if its bounds were smaller than its actual bounds, shifted to the top of screen. I can reproduce with the last version of SWT in a standalone snippet. Step to reproduce : OS configuration : OS X 10.7.3 Java : Oracle JVM 1.7 u 51, 64 bits SWT : SWT R-4.3-201306052000 To reproduce the issue with the provided snippet, try to drag the bottom text ("Some text... (Drag me to green area)") to the green drop target : I'm highlighting in red the actual bounds of mouse location recieved in the dragOver event. As you'll see, when the mouse pointer enters the drop target component, the dragEnter event is sent, then, immediately after, the dragExit comes, and after continuing dragging to the top of the component, several pixels upper, the dragOver component arrives. It's work fine on Windows. The issue was found when adapting a RCP Client for Java 1.7 OSX. The RCP client is based on Eclipse 3.8.2 R-3.8.2-201301310800 / org.eclipse.swt.cocoa.macosx.x86_64.source_3.8.1.v3836b.jar, with a patched SWT_AWT component according to https://bugs.eclipse.org/bugs/show_bug.cgi?id=374199. Regards, Joël
I too am experiencing this issue on OSX 10.8.5 and 10.9 (the only 2 platforms I have access to). I can confirm that the issue is present in Java 7u40, u45, u51, and Java 8 b132. My patch to Eclipse 3.8 is also based on the code from https://bugs.eclipse.org/bugs/show_bug.cgi?id=374199 I also grabbed SWT 3.102.v20140206-1334 from the latest Eclipse RCP Delta Pack and found the issue was also present in there. The x-coordinates of the drop spot appear to be correct. The y-coordinates appear to be shifted by the offset between the AWT Frame and the top of the SWT Shell. At least, this is what I see when I have an AWT Frame open in the Eclipse RCP "Editor Area" with only one tab group or with the tab groups split horizontally. When I split the tab group vertically, I have not been able to get Drag and Drop to work at all. I have tried making sure the AWT frame's "location" is matched to its location on screen and numerous other efforts with no luck (and no change). Also worth noting: the drag/drop bounding box is also offset. It is offset in both x and y axis and is related to the frame's offset from the SWT shell. The offset of the drag/drop bounding box is NOT THE SAME as the offset of the actual drop target. If I take the same panel with drag and drop and embed it in a regular JFrame, everything works. Also, dragging from the CViewEmbeddedFrame into a JFrame works and dragging from the JFrame into the CViewEmbeddedFrame is still broken. The issue is definitely in the drop acceptor. I'm not stranger to hacking around in the Eclipse code. This is a major problem for my product so I'm also willing to consider any workarounds proposed (no matter how ugly or reflection-ey). I'm so far completely stumped in terms of figuring out where the issue is.
This is problem is not seen with the previous embedded frame class for cocoa- "apple.awt.CEmbeddedFrame". While I'm still investigating, its possible that the issue is with the new class - "sun.lwawt.macosx.CViewEmbeddedFrame".
Deferring to 4.5.
We have not been able to work on this issue due to resource constraint. Setting the helpwanted tag, to get community help.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
This bug has been marked as stalebug a while ago without any further interaction. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard flag.
