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.
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
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.