Review request for 7124262: [macosx] Drag events go to a wrong child.
alexander.zuev at oracle.com
Mon Feb 27 05:35:08 PST 2012
On 2/27/12 14:39, Alexander Potochkin wrote:
> Hello Alexander
> In LWComponentPeer.removeDropTarget() you calladdDropTarget()
> this looks like copy-paste error
> it would also be great to give some more details about the unexpected
> conversion in CDropTarget class
Added all i know on the reason of why that happens, will help in the
future to understand of why we doing that transformation in that place.
New webrev is available at
With best regards,
>> On 2/22/12 20:13, Sergey Bylokhov wrote:
>>> 22.02.2012 21:51, Alexander Zuev wrote:
>>>> please review my fix for bug 7124262: [macosx] Drag events go to
>>>> a wrong child.
>>>> Bug description is
>>>> Webrev can be found here:
>>> I guess that old method code can be moved to LWWindowPeer?
>> I'm not sure about it - the fact that i can' figure out the situation
>> where we should register
>> drag recognizer and component is not in the hierarchy where root
>> component has the LWWindowPeer derived
>> peer doesn't mean that this situation is impossible. So i would let
>> this code be there.
>>> What about removeDropTarget()?
>> Yep - good catch - forgot that method.
>>> Why we need this import?
>>> import java.awt.peer.WindowPeer;
>> Artifact of the debugging. Removed.
>>> !winPeer.equals(this) could be replaced with !=?
>> In this case - yes. Fixed.
>> The new version of webrev available at
>> With best regards,
>> Alexander Zuev
>>>> We are incorrectly registering DropTarget listener in the
>>>> LWComponentPeer even if peer is not the LWWindowPeer
>>>> and because of that we are overriding the listener created for the
>>>> window itself so all the events come to the last added
>>>> AWT component.
>>>> With best regards,
>>>> Alexander Zuev
More information about the macosx-port-dev