Holding down keyboard keys on MacOS brings up special character menu

[Geokureli]

Copied from a Haxeflixel issue by @increpare. Moving the discussion, here as this will likely need to be fixed either here or in Lime.

• Haxe version: 4.2.5
• Flixel version: 5.6.2
• OpenFL version: 9.3.3-L3uoGG
• Lime version: 8.1.2
• Affected targets:
  MacOS 14.0 (23A344) - Apple M1 Max

---

Code snippet reproducing the issue:

Any project with a window will reproduce it. For instance, running the default flixel tpl -n "HelloWorld" project.

Possibly relevant settings system:
I have the "ABC - Extended" keyboard layout selected.

---

Observed behavior:

If I hold down certain keys on the keyboard that have variants/accents (like the A key, for instance), then a menu will appear to the top-left of the window (if in windowed mode) or screen (if fullscreen).

Expected behavior:

Unless I'm specifically inputting into a text field, I would not want this menu to appear. And in those cases, were it to appear, I would want it to appear in the correct location. Asking for perfect behaviour might be too much, but I would much prefer the menu never appear, rather than its current behaviour.

---

It is also present in other haxe games, like Dead Cells, so there must be some similarities in window instantiation/app settings.

(looking for games/apps that don't exhibit this behaviour, uh, it's not haxe I think, but VVVVVV and Aseprite don't)

Possible links to people possibly struggling with the same problem that I stumbled across while I was trying to solve it myself (sometimes it manifests as people reporting that key-repeats aren't getting sent):

https://apple.stackexchange.com/questions/332769/macos-disable-popup-showing-accented-characters-when-holding-down-a-key
https://www.reddit.com/r/runescape/comments/atudk0/macbook_whenever_i_press_and_hold_a_key_an_accent/
bus-stop/Termination#9
https://fsunuc.physics.fsu.edu/git/gwm17/glfw/commit/17a15a20f28ed95e0e69d403687416c023c77e7e
https://stackoverflow.com/questions/76546729/why-are-certain-repeated-keys-ignored-by-interpretkeyevents-in-nsresponder
https://fsunuc.physics.fsu.edu/git/gwm17/glfw/commit/17a15a20f28ed95e0e69d403687416c023c77e7e
smolck/uivonim#106 (comment)

[Geokureli]

Does dead cells use Lime? I wanna say it does, but He might be rolling his own entirely proprietary engine, in which case this may be a Haxe issue.

Based on what I know about lime/openfl, I assume this is due to how it uses a hidden text field to capture typing events, compared to keyboard events

Edit: Apparently, dead cells uses heaps, but it's possible heaps has the same implementation and issue

[joshtynjala]

SDL provides our native implementation of keyboard events and text input. This is likely something that will need to be fixed in SDL first. Not sure if they're aware of it, or have fixed it already. It might be worth trying the 8.2.0-Dev branch of Lime, which is using a newer version of SDL than the current stable release of Lime.

[increpare]

SDL provides our native implementation of keyboard events and text input. This is likely something that will need to be fixed in SDL first. Not sure if they're aware of it, or have fixed it already. It might be worth trying the 8.2.0-Dev branch of Lime, which is using a newer version of SDL than the current stable release of Lime.

For what it's worth, I just checked on lime directly (version 8.1.2) with the SimpleImage testproject ( https://lime.openfl.org/docs/home/ )

Happens both in macos and neko target:

And trying in 8.2.0-Dev, for both neko and macos targets, same behaviour:

Looking at SDL2-2.30.1 - going through the LazyFoo tutorial https://lazyfoo.net/tutorials/SDL/01_hello_SDL/mac/index.php , I get the same behaviour

I'll make a bug report on SDL, one sec...

[increpare]

libsdl-org/SDL#9268 (comment). explains how to fix the behaviour - by calling SDL_StopTextInput (the vvvvvv sourcecode on GitHub has example usage https://github.com/TerryCavanagh/VVVVVV if you search) - this is presumably something SDL want to keep enabled by default, so maybe better to deal with it here? I don't know how dependent on text input behaviour OpenFL is though, so I daren't suggest where to insert such calls (I can at least now throw it in my project, regardless 😅)

edit: putting this in my main files solves my problem.

var window = Application.current.window;
window.textInputEnabled = false;

I don't know what, if any, action openfl or HaxeFlixel will wish to take - I don't know the range of input behaviours of OpenFL at all, so I daren't suggest anything 😅. If It's not to be 'solved' in OpenFL here feel free to close this and I'll punt the question back up the chain :)

[joshtynjala]

We call SDL_StartTextInput() only when a TextField of type INPUT has focus. We call SDL_StopTextInput() when it no longer has focus.

It's odd if SDL calls SDL_StartTextInput() automatically by default without our intervention. I guess I'll look into it when I get a chance.