Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 428634

Summary: Drag and drop with SWT_AWT bridge broken on Mac OS X Java 1.7
Product: [Eclipse Project] Platform Reporter: Joël DRIGO <joel.drigo>
Component: SWTAssignee: Platform-SWT-Inbox <platform-swt-inbox>
Status: RESOLVED WORKSFORME QA Contact:
Severity: major    
Priority: P3 CC: abhishek.kishore, arunkumar.thondapu, jpeltzer, lshanmug, niraj.modi, petr.pchelko
Version: 3.8.2Keywords: helpwanted
Target Milestone: ---   
Hardware: Macintosh   
OS: Mac OS X   
Whiteboard: stalebug
Attachments:
Description Flags
The standalone snippet to reproduce the issue none

Description Joël DRIGO CLA 2014-02-20 06:26:40 EST 
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
Comment 1 James Peltzer CLA 2014-03-13 12:55:49 EDT 
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.
Comment 2 Abhishek Kishore CLA 2014-05-05 05:36:56 EDT 
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".
Comment 3 Arun Thondapu CLA 2014-05-06 04:30:49 EDT 
Deferring to 4.5.
Comment 4 Lakshmi P Shanmugam CLA 2015-05-11 05:37:31 EDT 
We have not been able to work on this issue due to resource constraint. Setting the helpwanted tag, to get community help.
Comment 5 Eclipse Genie CLA 2018-09-12 00:03:52 EDT 
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.
Comment 6 Lars Vogel CLA 2019-09-02 15:05:02 EDT 
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.
Comment 7 Lars Vogel CLA 2019-09-02 15:10:23 EDT 
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.