EVALUATION
On the Mac the getScreenInsets() dispatches the execution on the main thread. On Xtoolkit we aquire the AWTLock() when calling the Toolkit.getScreenInsets() method, so it looks like it should be OK for the method to block. Otherwise a similar hang would occur on X11 as well.
On the Mac we also call NSScreen.frame() just before calling the NSScreen.visibleFrame(). So it's really strange why the code didn't hang earlier since the implementations of both methods are quite identical. The only differnece is that at the lowest level they call either [NSScreen frame] or [NSScreen visibleFrame] methods, but otherwise there's no differences.
|
|
|
EVALUATION
Need more information:
1. What does a "Top Component" mean? What exactly needs to be dragged in what editor? Could you please provide a step-by-step instruction (what to create, where exactly to click, etc.) to reproduce the issue?
2. The EDT alone is not enough to investigate the issue. Could you attach a full thread dump to the bug please?
|
|
|
EVALUATION
I tried dragging a tool window and it hung with the stack trace as in the bug report. Also, I managed to get the full thread dump. Looks like the deadlock is happening between:
"AppKit Thread" daemon prio=5 tid=0x0000000100a2a800 nid=0x7fff70556cc0 runnable [0x00007fff5fbf9000]
java.lang.Thread.State: RUNNABLE
at sun.awt.dnd.SunDropTargetContextPeer.postDropTargetEvent(SunDropTargetContextPeer.java:583)
at sun.awt.dnd.SunDropTargetContextPeer.handleEnterMessage(SunDropTargetContextPeer.java:299)
which is sending a DnD event to Java and blocks until it's processed, and the AWTEventQueue thread which is trying to dispatch a call to [NSScreen visibleFrame] to the AppKit thread. It's still unclear to me why wouldn't the code hang earlier, when calling [NSScreen frame] which is happening before (see LWCToolkit.getScreenInsets()).
|
|
|
EVALUATION
Perhaps we could try to workaround this issue by caching the screen's frame/visibleFrame and not trying to re-request them every time we create a window. However, the creation of the window itself will need to be performed on the AppKit thread anyway. So it's not clear if this will ease the issue.
Maybe there's a way to postpone sending a DnD event until a mouse event that initiates the drag is completely processed, or some other solution. I'm reassigning the issue to a DragAndDrop expert for further evaluation.
|
|
|
Java