<AWT Dev> Possible fix for 6640765: Drop target management problem in XEmbeddedFramePeer

[Anthony Petrov]

Hi Brian,

Thanks for submitting a patch for this issue. I hope Petr, who is more 
familiar with the SWT_AWT bridge, could also take a look at this fix.

Note that you should base your patch on JDK 8 sources as initially a bug 
should be fixed in a development release. Only then can we consider 
porting it to an update release.

Some comments:

1. Java Plugin uses the XEmbeddedFramePeer as well. If you substitute 
this class in the rt.jar with a copy containing your changes, how does 
it affect applets that allow users to DnD? (such applets should be 
signed, obviously, because unsigned applets can't do DnD). This needs to 
be tested thoroughly to ensure we don't introduce a regression. If there 
was a way to detect that only a specific (swt-managed) XEFP really needs 
this additional processing, this might even be better, although I don't 
see a way to implement this easily. Also, running AWT DnD regression 
tests could be useful (see jdk/test/java/awt/ in the repo).

2. You should document the newly added boolean field and new methods 
with javadocs.

3. Could you please elaborate on the root cause of the issue? What code 
does call the addDropTarget() initially for an XEmbeddedFramePeer 
instance, and why exactly does it not get called for other instances of 
the peer class? BTW, why can't this be implemented on the SWT side of 
the bridge when processing regular focus events?

4. Should we protect from multiple calls to the registerDropTarget() 
just in case, or is it safe to register the same window multiple times?

5. All debugging println's should be removed from the patch.

6. Please add @Override annotations to methods that you override.

7. Formatting issues: you should add spaces after the "if" keywords. 
Also, the statements should either be one-liners w/o a {} block, or the 
blocks should be spread over multiple lines.

--
best regards,
Anthony

On 09/05/2013 01:00 AM, Brian de Alwis wrote:
> I'm helping with an Eclipse-based project that uses Eclipse's SWT_AWT facility to embed Swing within SWT.  SWT_AWT uses an embedded frame to host Swing/AWT content.  In this application, we frequently have several SWT_AWT-based editors open simultaneously, that support drag-and-drop, and have been hitting bug 6640765 (Eclipse bug 141893 [1]).  This is a Linux-specific bug where drops, when displaying several SWT_AWT embedded-frames, use the wrong frame.
>
> The original reporter on the Eclipse bug report identified the problem as something to do with XEmbeddedFramePeer.  I've tried to come up with a patch that solves the issue against JDK7 (attached).  I'm not very confident of the patch's correctness, but it seems to work in my application workflows.  I found I had to ensure that only a single embedded frame was registered as a drop target site.
>
> I fully admit that I am neither a proficient AWT hacker, nor with deep understanding of X11 DND.  Could someone with X11/AWT background provide some guidance as to whether this seems like a worthy fix, and pointers for how to build a unit test for this behaviour?
>
> Brian.
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=141893
>