Thanks, and thank you Martin for filing the issue https://bugs.openjdk.org/browse/JDK-8340982. I'll try to create an account on openjdk.org to be able to watch the issue :-).
Tangentially: For some reason mails on the openjfx-dev mailinglist coming from mar...@martinfox.com are not coming through to me. I only saw this thanks to Thiago's reply below (which prompted me to realize that I have missed Martin's mail). It's in the archives on https://mail.openjdk.org/pipermail/openjfx-dev/2024-September/thread.html alright, which is where I saw Martin's latest reply about filing the issue. It seems mails from m...@openjdk.org are coming through to me, but from mar...@martinfox.com not. Maybe some overzealous filtering by Gmail (not sure whether it's only an issue for me, or also for other gmail users). I'll try to investigate a bit more why gmail seems to be dropping these mails for me :-/. -- Johan On Wed, Sep 25, 2024 at 6:38 PM Thiago Milczarek Sayão < thiago.sa...@gmail.com> wrote: > Johan, > > Trust Martin, as I know nothing about Windows :) > Sorry for misleading you on the IME subject. > > Em qua., 25 de set. de 2024 às 13:24, Martin Fox <mar...@martinfox.com> > escreveu: > >> Johan, >> >> Thanks for providing all the details. It does sound like a bug. I will >> take a look. >> >> Since this is Windows altering the IME setup probably won’t have any >> effect. On Mac and Linux dead keys are delivered through the IME pathway >> and are presented to JavaFX as InputMethod events. On Windows dead keys >> don’t go through this pathway and are presented as KeyEvents. >> >> Martin >> >> On Sep 25, 2024, at 8:21 AM, Kevin Rushforth <kevin.rushfo...@oracle.com> >> wrote: >> >> I would not recommend internal APIs, unless someone wants to build JavaFX >> to help diagnose it. >> >> In any case it sounds like Johan has discovered a bug -- at least on >> Windows -- in the key handler for dead keys. We should test this on macOS >> and Linux as well. >> >> -- Kevin >> >> On 9/25/2024 8:14 AM, Thiago Milczarek Sayão wrote: >> >> Johan, >> >> It's an internal API, but we can use it for testing purposes (I'm not >> sure if there's a public API for that). >> SceneHelper.enableInputMethodEvents(scene, false); >> IME is used for entering complex characters in some languages such as >> Chinese, Korean, Japanese, etc. >> >> On Linux, setting the keyboard to en_US will also add the extra space, >> except if I choose the en_US with dead keys variation. >> >> If you try it on notepad, is it the same behaviour? If not, I think it >> might be a bug. >> >> -- Thiago. >> >> >> Em qua., 25 de set. de 2024 às 11:12, Johan Corveleyn <jcor...@gmail.com> >> escreveu: >> >>> Hi Thiago, >>> >>> Thank you for your answer. I am experiencing this issue on Windows >>> (Windows 10 and 11). >>> >>> Now, it dawns on me that: >>> - I have a QWERTY keyboard (standard US layout). >>> - I have my keyboard layout setting in Windows configured to "US >>> International". That way the keys for ~, ^, ', " become "dead keys" >>> (waiting for next keystroke). >>> - If I change my keyboard layout setting to "US" then I can't >>> reproduce anymore because those keystrokes no longer act like dead >>> keys (~, ^, ... immediately give that character). >>> >>> I don't know how this is handled on Linux or Mac. Do they also have >>> something like a "US International" keyboard layout setting so ^ >>> becomes a dead key? Or does it work differently if I want to type â or >>> ë, or a standalone ^? >>> >>> I'm not sure what you mean by disabling IME or how to know that it's >>> enabled. Can I enable/disable this programmatically in JavaFX? Or is >>> this an OS keyboard layout setting (anyway: just having a standard "US >>> input" makes this non reproducible because I can no longer type dead >>> keys)? >>> >>> If you have a keyboard input with dead keys it's super easy to test >>> this with a simple program like: >>> [[[ >>> public class DeadKeysFX extends Application { >>> @Override >>> public void start(Stage stage) { >>> TextField textField = new TextField(); >>> Scene scene = new Scene(textField); >>> stage.setScene(scene); >>> stage.show(); >>> } >>> } >>> ]]] >>> >>> Just type ^+<space> and see whether you get one or two characters. In >>> all non-JavaFX programs (including Java Swing) I get a single '^'. In >>> JavaFX I get a '^ '. >>> >>> -- >>> Johan >>> >>> On Tue, Sep 24, 2024 at 5:16 PM Thiago Milczarek Sayão >>> <thiago.sa...@gmail.com> wrote: >>> > >>> > Hi Johan, >>> > >>> > It might vary be platform. Which one are you using? (Windows, Mac, >>> Linux). >>> > >>> > Try disabling IME (Input Method Editor) and see it it works. >>> > >>> > - Thiago >>> > >>> > Em ter., 24 de set. de 2024 11:51, Johan Corveleyn <jcor...@gmail.com> >>> escreveu: >>> >> >>> >> Hi, >>> >> >>> >> (This is my first post here, hope I'm following the right path) >>> >> >>> >> It seems JavaFX TextFields (and friends) do not automatically convert >>> >> <dead key>+<space> into simply <dead key character>. They make it into >>> >> <dead key character>+<space>, which is very atypical. I would consider >>> >> this behavior a bug, since it is different from any editor I know (and >>> >> makes it very hard to enter a dead key character on its own). We ran >>> >> into this with Java 8, I also reproduced it with openjdk 21 + openjfx >>> >> 23. >>> >> >>> >> For instance if in a JavaFX TextField I type a '^' keystroke, it waits >>> >> for the next keystroke (which is normal since it's a dead key, >>> >> possibly followed by a character on which to put the '^'). But if I >>> >> then type <space> I expect a simple '^' to appear. Instead, in JavaFX, >>> >> '^ ' appears. This does not happen in Swing, nor in any editor or >>> >> shell or ... >>> >> >>> >> Background context: a user of our JavaFX application couldn't >>> >> authenticate with their password (typed in a PasswordField). After an >>> >> awful lot of troubleshooting we found that they used a '^' in their >>> >> password. Of course the user didn't notice that after typing ^+space >>> >> two dots appeared in the PasswordField. Now that user knows they have >>> >> to backspace after typing ^+space ... >>> >> >>> >> I suppose inserting a Swing JPasswordField in our JavaFX app would >>> >> work around this issue, but ... isn't there a better solution? >>> >> Shouldn't this be regarded as a bug? >>> >> >>> >> -- >>> >> Johan >>> >> >> >>
