Tk Source Code

On transitioning a cross platform application to Tk 8.5+ on macOS, we've run into a bug where <KeyRelease> events are being generated immediately after <KeyPress> events when pressing a key and *not* when releasing a key. This makes <KeyRelease> largely useless for detecting proper key hold states.

This is not related to system key repeat settings.

Here's a minimal test to try with wish:

package require Tk

bind . <KeyPress>   {puts "press   %K"}
bind . <KeyRelease> {puts "release %K"}

Bug behavior:

1. press key

2. two events generated: <KeyPress> then <KeyRelease>

3. release key

Expected behavior:

1. press key

2. one event generated: <KeyPress>

3. release key

4. one event generated: <KeyRelease>

Tested on macOS 10.12.6 with:

* 8.4 on system: expected behavior

* 8.5.9 on system: alternate behavior with 3 events on press: <KeyPress>, <KeyRelease>, then <KeyPress> (but it's known to be buggy in general)

* 8.5.19: bug behavior

* 8.6: not tested

* 8.7 Github master branch: bug behavior

Original project issue for reference: https://github.com/pure-data/pure-data/issues/213

Yes, please do open a new ticket.  I think this is a RFE - respect the
system preferences setting which turns key repeat off.

Without studying the code, this is what I remember.  Apple's key event
has a field which flags a key event as a "repeat".  They do not send
separate press and release events when a key is held down and starts
repeating.  But Tk does do that.  When a keyPress event arrives with the
aRepeat flag set to YES, Tk generates a release followed by a press.
There are two other fields in the event which relate to repeating:
keyRepeatDelay and keyRepeatInterval.  Tk ignores those, but I assume
that they reflect the preferences setting.  I would guess that it is
the keyRepeatInterval that indicates whether key repeat is turned off.
Maybe they set it to infinity?  Who knows.  You certainly would not
expect to find an answer to that in Apple's documentation, and I did
not see it there.

On 10.15.7 Catalina (even when using a clean “guest” user profile), when I set “Key Repeat” to “off”, I continue to observe key repeating in any app; the only effect it seems to have is forcing a certain “delay until repeat” value. So maybe that is a macOS or AppKit bug, as AppKit is sending repeat key events anyway, and [NSEvent keyRepeatDelay] appears to be unaffected. (If it were a macOS bug, though, I might expect to find others’ reports of this issue elsewhere.)

my mistake, the bug is actually that key repeat events are generated even if set to disabled in system preferences (should [NSEvent keyRepeatDelay] < 0 be checked somewhere perhaps?). Should I open a new bug report?

I cannot reproduce this with the current core-8-6-branch.  One line is
printed when I press the key and another line is printed when I release
the key.  If I hold the key down for too long it starts repeating and I
get lots of press-release pairs.

I have not verified the existence of this issue in 8.6.11 or core-8-6-branch, but would point out that 8.6.11 includes significant rework to address [585584ad66] and other issues which sound related to this one.

I'm getting this error again in tk 8.6.11 on osx 10.14.6 (mojave)

Branch mac-keyrelease-test merge to 8.6 and trunk.

Branch mac-keyrelease-test, just committed, appears to address the issue. Please test.

Branch mac-keyrelease-test, just committed, appears to address the issue. Please test.

I an old patch lying around that I've applied to commit [e8961ae643c31f02], but no longer have a relevant system to test it on. Does it perhaps resolve this issue?

--- macosx/tkMacOSXKeyEvent.c
+++ macosx/tkMacOSXKeyEvent.c
@@ -198,11 +198,11 @@
               }
 
               if (repeat) {
                 Tk_QueueWindowEvent(&xEvent, TCL_QUEUE_TAIL);
                 xEvent.xany.type = KeyPress;
-                xEvent.xany.serial = LastKnownRequestProcessed(Tk_Display(tkwin));
+                xEvent.xany.serial = LastKnownRequestProcessed(Tk_Display(tkwin)) - 1;
               }
             }
             Tk_QueueWindowEvent(&xEvent, TCL_QUEUE_TAIL);
             savedModifiers = modifiers;
             return theEvent;