JDK-7142565 : [macosx] Many special keys processed twice in text fields
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7,7u4,8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-02-03
  • Updated: 2012-06-06
  • Resolved: 2012-03-13
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 7 JDK 8
7u4 b13Fixed 8Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
In the latest builds of jdk7u-osx and jdk7u-dev arrow keys are interpreted twice when pressed. This is easy to reproduce in Bugster. Just go to any text input area with some text, click at the beginning of the text, and press the right arrow key. You'll see that the cursor moves ahead two characters.

The same is true for the up and down arrows -- open the 'Priority' popup menu and use the arrows to move up and down in the list. You'll jump ahead or back two lines.

Finally, forward delete is also handled twice, although there's a second bug there in that you see two rectangles in addition to the two characters being deleted.

Comments
SUGGESTED FIX http://cr.openjdk.java.net/~ant/7142565/
08-02-2012

EVALUATION To workaround this behaviour the following fix is suggested. A pointer to the latest key event processed in AWTView.m is stored and the next event is compared to the previous one. If the pointers refer to the same object it means the event is delivered to keyDown: repeatedly (after it has been delivered to performKeyEquivalent:). In such case the second event is ignored.
08-02-2012

EVALUATION AWTView -performKeyEquivalent: returns NO which causes the OS to also generate a keyDown: event. So in fact this is a regression of 7131196 which actually reverted the return value of performKeyEquivalent: from YES to NO.
07-02-2012