JDK-8046495 : KeyEvent can not be accepted in quick mouse clicking
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6u75,8u5,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-06-11
  • Updated: 2015-01-21
  • Resolved: 2014-07-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8 JDK 9
6u91Fixed 7u76Fixed 8u40Fixed 9 b28Fixed
Related Reports
Relates :  
Relates :  
Description

When a program show a dialogue, user presses ESC key and left-button of mouse
so quickly and repeatedly, ESC KeyEvent can not be accepted.

This occurs only in jdk6ux, not in jdk7ux.
 

Comments
UR SQE perfromed PIT with the fix. http://st2.ru.oracle.com/StatusTool2/faces/queryresult2.jsp?matrix_id=1000029191 No specific to the fix issues found. OK to take in PSU15_01
17-11-2014

The idea of the fix is just to use JVM_CurrentTimeMillis only as events timestamp. On Mac this is done in exactly the same way: CPlatformResponder.handleMouse/KeyEvent() The message time offset calculation has been introduced with the fix for JDK-4434193 and it seems that the issue has addressed very similar problem: At times getWhen()in ActionEvent returns higher value than the CurrentSystemTime. I didn't find any benefits in using the existing approach: - all the usages of the TimerHelper are in fact reduced to the mentioned formula: when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime()) - GetMessageTime() always increases (except of the int overflow moments), thus we couldn't get earlier OS messages after later ones - TimerHelper::windowsToUTC(DWORD windowsTime) doesn't guarantee returning the same timestamp across different calls for the same message time
01-07-2014

Here is a log snapshot of calculating the timestamps for window input events in the TimeHelper::windowsToUTC() function --- tickCount=881985379, windowsTime=881985379, offset=0, jvm_time=1403796332508, ret=1403796332508 --- tickCount=881985379, windowsTime=881985379, offset=0, jvm_time=1403796332508, ret=1403796332508 --- tickCount=881985379, windowsTime=881985379, offset=0, jvm_time=1403796332508, ret=1403796332508 --- tickCount=881985395, windowsTime=881985379, offset=16, jvm_time=1403796332518, ret=1403796332502 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985426, windowsTime=881985426, offset=0, jvm_time=1403796332558, ret=1403796332558 --- tickCount=881985473, windowsTime=881985473, offset=0, jvm_time=1403796332608, ret=1403796332608 --- tickCount=881985473, windowsTime=881985473, offset=0, jvm_time=1403796332608, ret=1403796332608 --- tickCount=881985473, windowsTime=881985473, offset=0, jvm_time=1403796332608, ret=1403796332608 --- tickCount=881985473, windowsTime=881985473, offset=0, jvm_time=1403796332608, ret=1403796332608 --- tickCount=881985473, windowsTime=881985473, offset=0, jvm_time=1403796332608, ret=1403796332608 --- tickCount=881985489, windowsTime=881985473, offset=16, jvm_time=1403796332618, ret=1403796332602 (!!! earlier time) --- tickCount=881985504, windowsTime=881985489, offset=15, jvm_time=1403796332628, ret=1403796332613 --- tickCount=881985504, windowsTime=881985489, offset=15, jvm_time=1403796332628, ret=1403796332613 --- tickCount=881985535, windowsTime=881985535, offset=0, jvm_time=1403796332668, ret=1403796332668 --- tickCount=881985535, windowsTime=881985535, offset=0, jvm_time=1403796332668, ret=1403796332668
01-07-2014

On Windows we have some algorithm for calculating input event timestamp: jdk/src/windows/native/sun/windows/awt_Component.cpp:2100 Shortly the timestamp is calculated by the following formula: when = JVM_CurrentTimeMillis() - (GetTickCount() - GetMessageTime()) Where: JVM_CurrentTimeMillis() - the same as System.currentTimeMillis() GetTickCount() - Win32 function, current millis from boot time GetMessageTime() - Win32 function, millis from boot time of the latest native Message In theory the formula looks good: we are trying our best to calculate the actual time of the OS message by taking the current JVM time (JVM_CurrentTimeMillis) and adjusting it with the offset (GetTickCount - GetMessageTime) which should indicate how many milliseconds ago from the current moment (GetTickCount) the message has been actually issued (GetMessageTime). In practice due to usage of different system timers by the JVM_CurrentTimeMillis and GetTickCount their values are not updated synchronously and we may get an earlier timestamp for the later event.
01-07-2014

The problem is reproducible with Key presses only. It appeared that the later KeyEvent may sometimes have an earlier timestamp.
26-06-2014

Adding more reliable testcase
17-06-2014