<AWT Dev> <AWT dev> Review Request for 8006941 : [macosx] Deadlock in drag and drop & 7199783 : Setting cursor on DragSourceContext does not work on OSX

Denis S. Fokin denis.fokin at oracle.com
Thu Feb 28 00:44:48 PST 2013

Hi Petr,

I have noticed a couple of things in your fix.

Previously we checked the root for null. According to the javadoc we 
still can get one. This can lead to a NPE.
  423                             Component root = 
  424                             Point rootLocation = 

I would say that visibility and isEnabled() value do not make sense here.
  449         if (!(root.contains(x, y) && root.isVisible() && 
root.isEnabled())) {

Where we are posting dragExit and dragEnter messages now? Is it the 
event dispatching issue that you have mentioned?

Could you reformat lines according to our code style?
Some of them are really long. See

What do you think about camel notation here. Even "Coding Guidelines for 
Cocoa" suggets it and it is easier to understend for java porgrammer.
87 - (id)init:(jobject)jdragsourcecontextpeer 
component:(jobject)jcomponent peer:(jobject)jpeer control:(id)control

Thank you,

On 2/27/2013 5:43 PM, Petr Pchelko wrote:
> Hello, AWT Team.
> Please, review the fix for 2 issues:
> http://bugs.sun.com/view_bug.do?bug_id=7199783  Setting cursor on DragSourceContext does not work on OSX
> http://bugs.sun.com/view_bug.do?bug_id=8006941  Deadlock in drag and drop
> The fix is available at:
> http://cr.openjdk.java.net/~pchelko/8006941/webrev.02/
> I have made a single fix for these 2 issues, because they are quite closely related, and the same methods need to be changed. And they depend on one another quite a bit.
> 1. The deadlock occurred because in CDragSourceContextPeer.dragMouseMoved methods on components were invoke on the Appkit thread. They blocked on an AWTTreeLock if EDT had already took it. EDT trying to perform a sync selector on the Appkit thread lead to a deadlock. So the logic of working with components are moved to the EDT now.
> 2. DragSource events were dispatched absolutely incorrectly. Now we dispatch them the same way as on other platforms.
> 3. CCursorManager contained a workaround for the issue that we were not able to perform sync selectors during the dnd. Now sync selectors are processed during drag, so this workaround is not needed any more.
> 4. The functionality to set a cursor in DragSourceListeners is implemented. It works, however it still has a couple of issues:
> 	a. Sometimes mouse events are dispatched during the dnd, which might reset a cursor. That is wrong, mouse events should not be dispatched. It is a separate issue, so this problem will disappear as mouseEvent dispatching would be fixed.
> 	b. If the DropTarget supports NSDragOperationCopy cocoa sets an NSDragCopyCursor. There is no API to disable this and I have found no suitable workaround.
> 	c. On the first drag in the lifetime of the application cursor is not set. This is due to a bug in cocoa. They reset a cursor in some setter which looks absolutely unrelated and called when the first dragging session is initialized. I am thinking about filing a bug against apple.
> 5. Some cleanup: removed unused variables.
> With best regards. Petr.

More information about the awt-dev mailing list