<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Johan,</div><div><br></div><div>Thanks for providing all the details. It does sound like a bug. I will take a look.</div><div><br></div><div>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.</div><div><br></div><div>Martin</div><div><div><br><blockquote type="cite"><div>On Sep 25, 2024, at 8:21 AM, Kevin Rushforth <kevin.rushforth@oracle.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div>
I would not recommend internal APIs, unless someone wants to build
JavaFX to help diagnose it.<br>
<br>
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.<br>
<br>
-- Kevin<br>
<br>
<div class="moz-cite-prefix">On 9/25/2024 8:14 AM, Thiago Milczarek
Sayão wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAAP_wuk+pZmmywHtOCL__h3JfHynyqLj_s7J3E8PtDoWqGN8Cg@mail.gmail.com">
<div dir="ltr">Johan,
<div><br>
</div>
<div>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).</div>
<div>SceneHelper.enableInputMethodEvents(scene, false);<br>
</div>
<div>IME is used for entering complex characters in some
languages such as Chinese, Korean, Japanese, etc.<br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>If you try it on notepad, is it the same behaviour? If not,
I think it might be a bug.</div>
<div><br>
</div>
<div>-- Thiago.</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Em qua., 25 de set. de 2024 às
11:12, Johan Corveleyn <<a href="mailto:jcorvel@gmail.com" moz-do-not-send="true" class="moz-txt-link-freetext">jcorvel@gmail.com</a>>
escreveu:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
Thiago,<br>
<br>
Thank you for your answer. I am experiencing this issue on
Windows<br>
(Windows 10 and 11).<br>
<br>
Now, it dawns on me that:<br>
- I have a QWERTY keyboard (standard US layout).<br>
- I have my keyboard layout setting in Windows configured to
"US<br>
International". That way the keys for ~, ^, ', " become "dead
keys"<br>
(waiting for next keystroke).<br>
- If I change my keyboard layout setting to "US" then I can't<br>
reproduce anymore because those keystrokes no longer act like
dead<br>
keys (~, ^, ... immediately give that character).<br>
<br>
I don't know how this is handled on Linux or Mac. Do they also
have<br>
something like a "US International" keyboard layout setting so
^<br>
becomes a dead key? Or does it work differently if I want to
type â or<br>
ë, or a standalone ^?<br>
<br>
I'm not sure what you mean by disabling IME or how to know
that it's<br>
enabled. Can I enable/disable this programmatically in JavaFX?
Or is<br>
this an OS keyboard layout setting (anyway: just having a
standard "US<br>
input" makes this non reproducible because I can no longer
type dead<br>
keys)?<br>
<br>
If you have a keyboard input with dead keys it's super easy to
test<br>
this with a simple program like:<br>
[[[<br>
public class DeadKeysFX extends Application {<br>
@Override<br>
public void start(Stage stage) {<br>
TextField textField = new TextField();<br>
Scene scene = new Scene(textField);<br>
stage.setScene(scene);<br>
stage.show();<br>
}<br>
}<br>
]]]<br>
<br>
Just type ^+<space> and see whether you get one or two
characters. In<br>
all non-JavaFX programs (including Java Swing) I get a single
'^'. In<br>
JavaFX I get a '^ '.<br>
<br>
--<br>
Johan<br>
<br>
On Tue, Sep 24, 2024 at 5:16 PM Thiago Milczarek Sayão<br>
<<a href="mailto:thiago.sayao@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">thiago.sayao@gmail.com</a>>
wrote:<br>
><br>
> Hi Johan,<br>
><br>
> It might vary be platform. Which one are you using?
(Windows, Mac, Linux).<br>
><br>
> Try disabling IME (Input Method Editor) and see it it
works.<br>
><br>
> - Thiago<br>
><br>
> Em ter., 24 de set. de 2024 11:51, Johan Corveleyn <<a href="mailto:jcorvel@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">jcorvel@gmail.com</a>>
escreveu:<br>
>><br>
>> Hi,<br>
>><br>
>> (This is my first post here, hope I'm following the
right path)<br>
>><br>
>> It seems JavaFX TextFields (and friends) do not
automatically convert<br>
>> <dead key>+<space> into simply <dead
key character>. They make it into<br>
>> <dead key character>+<space>, which is
very atypical. I would consider<br>
>> this behavior a bug, since it is different from any
editor I know (and<br>
>> makes it very hard to enter a dead key character on
its own). We ran<br>
>> into this with Java 8, I also reproduced it with
openjdk 21 + openjfx<br>
>> 23.<br>
>><br>
>> For instance if in a JavaFX TextField I type a '^'
keystroke, it waits<br>
>> for the next keystroke (which is normal since it's a
dead key,<br>
>> possibly followed by a character on which to put the
'^'). But if I<br>
>> then type <space> I expect a simple '^' to
appear. Instead, in JavaFX,<br>
>> '^ ' appears. This does not happen in Swing, nor in
any editor or<br>
>> shell or ...<br>
>><br>
>> Background context: a user of our JavaFX application
couldn't<br>
>> authenticate with their password (typed in a
PasswordField). After an<br>
>> awful lot of troubleshooting we found that they used
a '^' in their<br>
>> password. Of course the user didn't notice that after
typing ^+space<br>
>> two dots appeared in the PasswordField. Now that user
knows they have<br>
>> to backspace after typing ^+space ...<br>
>><br>
>> I suppose inserting a Swing JPasswordField in our
JavaFX app would<br>
>> work around this issue, but ... isn't there a better
solution?<br>
>> Shouldn't this be regarded as a bug?<br>
>><br>
>> --<br>
>> Johan<br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</div></blockquote></div><br></div></body></html>