On 9/27/2016 7:09 PM, Sergey Bylokhov wrote:
On 04.08.15 14:54, Semyon Sadetsky wrote:
On 8/3/2015 6:05 PM, Sergey Bylokhov wrote:
Hi, Semyon
Did you try to change dwMilliseconds from INFINITE to the timeout(10
seconds by default?) which is passed to the method? It does not help?
Because even when dnd is not used we should not wait event for
infinite time.
It would not help to fix the issue because 10 seconds is too big
interval. But for consistency it is not bad to have a time limit.
http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.01/
Looks fine. Please file separate issue that syncNativeQueue() should
check that dnd callbacks are started/completed, because
"(newEventNumber - eventNumber) > 2" check is useless if we are in the
DND. And if some callbacks are in progress syncNativeQueue() should
notify the java side that we should call syncNativeQueue() one more time.
I have modified the fix to take the above into account. The updated
webev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.02/
On 03.08.15 17:26, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8132664
webrev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.00/
DoDragDrop() is blocking, so upon drag operation is triggered the
toolkit thread is blocked and the WM_AWT_WAIT cannot be processed
which in its turn blocks the AWT robot.
The solution is to escape AWT robot waiting in syncNativeQueue() if
drag operation is in progress.
--Semyon
