Dead keys followed by space

[Thiago Milczarek Sayão]

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 <jcorvel at 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.sayao at 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 <jcorvel at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20240925/ec3ef3d6/attachment.htm>