Community
Participate
Working Groups
This issue was spotted whilst discussing Bug 550059. SWT components that rely on the win32 Widget class to handle keyboard input no longer handle some key combinations on recent Windows 10 versions. So far, I've managed to reproduce the issue with Windows 10 build 18362.356. Older builds such as 17763.557 and 17763.678 are unaffected. Markus Keller has been able to reproduce the issue as well, however, I'm not sure what his build number is. The issue seems to happen with keyboard layouts that feature dead keys (e.g. French, German, US-Int, etc.). For instance, when using a French layout, pressing AltGr+é twice in a row should result in ~~ (the first AltGr+é press does not produce any character, hence the dead key terminology), but now nothing happens due to this issue. To test this on an English keyboard, enable the FR layout and press AltGr+2. I'm obviously not familiar with all keyboard layouts, but characters such as ~`^ may have become impossible to type in Eclipse depending on the layout. Concrete impact example: the IDE has pretty much become unusable when editing markdown files for some developers, as you can't insert code blocks using backticks anymore. Note that this is likely a change in OS behaviour, and therefore impacts pretty much any Windows Eclipse version, even from many years ago - I can reproduce this issue on Eclipse 2019-09 as well as on Oxygen.
I've done a bit of debugging using my French"azerty" layout. As a reminder, here is the sequence of WM_KEYDOWN and WM_CHAR messages that I had observed when typing ~~ (AltGr+é, AltGr+é) whilst working on Bug 219750: > * holding AltGr sends multiple pairs of WM_KEYDOWN messages alternating > between wParam 17 and 18. None of these messages send events downstream. > * when AltGr+é is combined for the first time, one WM_KEYDOWN message with > wParam 50, corresponding to the é key. This one is ignored as the > PeekMessage function indicates that there is a WM_DEADCHAR on the message > queue. This sets display.lastDead to true. > * when AltGr+é is combined for the second time (the user releases 'é' and > holds it down again), another WM_KEYDOWN message with wParam 50 is sent. > This one isn't ignored as there is no more WM_DEADCHAR on the message queue. > An event for character 'é' is sent to the StyledText widget. > * this second AltGr+é combination also triggers two consecutive WM_CHAR > messages with messages with wParam 126. Two event for character '~' are sent > to the StyledText widget. On the newer version of Windows 10 I'm now using, I'm still seeing the WM_KEYDOWN messages as described above, however, the Widget class is no longer receiving any WM_CHAR messages, therefore no '~' characters are being typed at all.
Just updated to a new Windows 10 build version, 18362.387, I can confirm that the issue is still present.
Just an idea from a quick glance at https://docs.microsoft.com/de-ch/windows/win32/api/winuser/nf-winuser-translatemessage and https://docs.microsoft.com/de-ch/windows/win32/winmsg/using-messages-and-message-queues : Windows seems to expect applications to use TranslateMessage, but in https://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt/Eclipse%20SWT/win32/org/eclipse/swt/widgets/Display.java?id=f0b73475478efca056e12636404cbaae25b1f985#n3014 , I see that SWT doesn't do that for keys in Display.ACCENTS. Maybe Microsoft assumed everyone uses their suggested message loop structure and moved some reponsibilities from one of the functions in the "standard" loop to another. That could explain why most apps continue to work, but Eclipse has trouble now.
*** Bug 552213 has been marked as a duplicate of this bug. ***
*** Bug 559071 has been marked as a duplicate of this bug. ***
OS.ToUnicode call in Display.asciiKey() is eating dead key state. Let's see if it can be fixed.
This regression is caused by PeekMessage failing unexpectedly in Widget.wmKeyDown when testing for WM_DEADCHAR in the queue: int flags = OS.PM_NOREMOVE | OS.PM_NOYIELD | OS.PM_QS_INPUT | OS.PM_QS_POSTMESSAGE; if (OS.PeekMessage (msg, hwnd, OS.WM_DEADCHAR, OS.WM_DEADCHAR, flags)) Removing category filters PM_QS_INPUT and PM_QS_POSTMESSAGE makes it work again. Looks like a Windows bug to me, because WM_DEADCHAR is posted by TranslateMessage and should match PM_QS_POSTMESSAGE. Note that this doesn't magically solve other dead key bugs in SWT (like Bug 550059).
New Gerrit change created: https://git.eclipse.org/r/156122
Gerrit change https://git.eclipse.org/r/156122 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a8d1888e9c7d6b525acf5b367afde6774a260a65
Thanks for the patch, this will be a big improvement for a lot of users!
*** Bug 559974 has been marked as a duplicate of this bug. ***
