Johan, I’ve entered a bug, https://bugs.openjdk.org/browse/JDK-8340982.
In general if you type a dead key followed by a character that can’t combine with it you get two characters. For example, if you type a dead key circumflex followed by a ‘q’ you should see “^q”. The Space character is an exception, on all platforms a dead key followed by a Space should yield just one character. The Windows platform code is mishandling this case. Thanks for bringing this up. Martin > On Sep 25, 2024, at 9:38 AM, 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 > <mailto: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 >>> <mailto: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 >>>> <mailto: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 <mailto: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 >>>>> > <mailto: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 >>> >>
