Since 0.12.0 keyboard input does not work (macOS)

[daletman]

For bug reports, the following information can help speed up the process. Please
describe the bug that you have found and what you would expect to happen
instead.

System

OS: macOS 12.6.3 (21G419)
Version: alacritty 0.12.0 (5a72819)

Logs

Font/Terminal size: Alacritty-75137.log

When I start Alacritty using the App Icon or Spotlight, the keyboard input (except Enter, Escape, Backspace and maybe some more) does not work. When I start Alacritty from Terminal it works just fine. Also tested using the default config.

[chrisduerr]

Is there a difference to env with and without starting it from a terminal?

[daletman]

I don't think so. Here is my output of env when startet from terminal. I can't give you the output when not startet from termninal since I can't type.

ALACRITTY_LOG=/var/folders/my/gzz9nv7x0wq45khvl83pv4br0000gn/T/Alacritty-87920.log
ALACRITTY_SOCKET=/var/folders/my/gzz9nv7x0wq45khvl83pv4br0000gn/T/Alacritty-87920.sock
ALACRITTY_WINDOW_ID=140599583879712
AUTOJUMP_ERROR_PATH=/Users/home/Library/autojump/errors.log
AUTOJUMP_SOURCED=1
COLORTERM=truecolor
FIGTERM_SESSION_ID=10a28307-c551-44c9-b946-d8978bca5f03
FIG_PID=87922
FIG_SET_PARENT=10a28307-c551-44c9-b946-d8978bca5f03
FIG_SET_PARENT_CHECK=1
FIG_TERM=2.14.2
HOME=/Users/home
LC_FIG_SET_PARENT=10a28307-c551-44c9-b946-d8978bca5f03
LOGNAME=home
LaunchInstanceID=B5A35957-A8FE-47C0-8E8E-E55675477347
NNN_PLUG=f:finder;o:fzopen;p:preview-tui;d:diffs;v:imgview;m:mimelist
OLDPWD=/Users/home
P9K_TTY=old
PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Applications/Wireshark.app/Contents/MacOS:/Applications/Postgres.app/Contents/Versions/latest/bin:/Users/home/.cargo/bin:/Users/home/.fig/bin:/Users/home/.local/bin
PWD=/Users/home
SECURITYSESSIONID=186e2
SHELL=/bin/zsh
SHLVL=2
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.uqAP0HBpvq/Listeners
TERM=alacritty
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=445
TERM_SESSION_ID=4012853C-FD39-49BF-A0B0-8A0B1C6D667D
TMPDIR=/var/folders/my/gzz9nv7x0wq45khvl83pv4br0000gn/T/
TTY=/dev/ttys009
USER=home
WINDOWID=140599583879712
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0
_P9K_SSH_TTY=/dev/ttys009
_P9K_TTY=/dev/ttys009
__CFBundleIdentifier=com.apple.Terminal
__CF_USER_TEXT_ENCODING=0x0:0:2
P9K_SSH=0
LC_CTYPE=UTF-8
_=/usr/bin/env

[daletman]

I could run env through history because arrow up does work. There is no difference.

[kchibisov]

Could you try do get a log from the app with persistent_logging and print_events from the debug section, using the default config

alacritty/alacritty.yml

Line 883 in 2df8f86

#debug:

The place where log file will be saved could be obtained by running with this config from the terminal.

[daletman]

Here is the log file when not starting from terminal using my personal config file (not the default):
Alacritty-90697.log

[monsterhxw]

same issue.

[chrisduerr]

@daletman Did you perform any keyboard input during this log?

[kchibisov]

This is sort of suspicious.

Using fallback locale: UTF-8

@daletman also, it seems like you haven't enabled the print_events log?

[dincercelik]

Same issue.

OS: 13.3 (22E252)
Version: 0.12.0 (1)

[tetzng]

Same issue.

I typically alternate between alphanumeric and Japanese input, with the default set to alphanumeric. In my case, when I switch to Japanese input and type any text, then switch back to alphanumeric, I am able to input alphanumeric characters.

[tetzng]

I typically alternate between alphanumeric and Japanese input, with the default set to alphanumeric. In my case, when I switch to Japanese input and type any text, then switch back to alphanumeric, I am able to input alphanumeric characters.

Oh, but if the window loses focus, I can't input alphanumeric characters again.
Similarly, I can't input alphanumeric characters unless I have first entered any text using Japanese input.

[kchibisov]

There's not a single log that could help unfortunately, as in the one with --print-events output, which has keyboard input captured.

[tetzng]

This is the log with only print-events changed to true in the Default config
Alacritty-64626.log

macOS: 13.2.1(22D68)
version: 0.12.0(5a72819)

[kchibisov]

I'd assume that you've tried to type something? Because it shows that you've pressed spacebar once and that was about it?

[daletman]

@chrisduerr @kchibisov

Here is a new log file with print-events set to true. Alacritty not started from terminal, after Alacritty started I type the letters asdf on german keyboard layout:

Alacritty-99660.log

[Prenoult]

I got the same issue, except when I launch alacritty with the alacritty command in another console everything works well.

[pbgc]

@kchibisov This is very strange because I have the same exact system:

OS: macOS 12.6.3
Version: alacritty 0.12.0

And don't have this problem ! (I have used all the RC without this problem). If I can help in comparing something etc ... just ask!

[sly01]

Same issue here.

[gzm55]

maybe this bug only affects some IME. I've two non-ABC IME, one has same issue, another is fine.

[astounding-rbereziuk]

Same issue:
OS: 13.2.1 (22D68)
Alacritty: 0.12.0

If start from the terminal all good, but launchpad keyboard doesn't work

[jansol]

Potentially related: window.option_as_alt seems to completely break input if I set it to something other than None and attempt to type something that requires pressing option to type. (e.g. @ on apple's nordic layout).

If I hit ctrl+c or enter it starts working again.

[pbgc]

@jansol

Potentially related: window.option_as_alt seems to completely break input if I set it to something other than None and attempt to type something that requires pressing option to type. (e.g. @ on apple's nordic layout).

check #6720 and "macOS Alt/Option situation" entry in https://github.com/alacritty/alacritty/releases/tag/v0.12.0-rc1

[jansol]

I saw that, but is it really intended that it also eats at least one unrelated key after I let go of the key combo? (I think I got it to eat multiple too, but couldn't reproduce that reliably yet)

[pbgc]

@jansol
I have a portuguese layout keyboard and in my alacrity.yml :

window:
  option_as_alt: Both

key_bindings:
  - { key: LBracket,      mods: Alt,            chars: "\x5B"                }
  - { key: RBracket,      mods: Alt,            chars: "\x5D"               }
  - { key: Key2,             mods: Alt,            chars: "\x40"               }
  - { key: Key3,             mods: Alt,            chars: "€"                    }
  - { key: LBracket,      mods: Alt|Shift,      chars: "\x7B"             }
  - { key: RBracket,      mods: Alt|Shift,      chars: "\x7D"            }

and everything works perfectly (for me since RC2)! I use alacritty alone, with tmux and several editors (Emacs, Helix) locally and via ssh and 0.12 is the best release until now! No eated keys nor nothing similar to the mains issue described.

[kchibisov]

@pbgc the issue with some setups here is that they don't have any input from the keyboard, like at all. And the cause for that could be more complicated than what patches were sent upstream, simply because the macOS backend changed lots of internals upstream and the upstream maintainer is not available at the time being.

I'll try to prepare some patches over the weekends to at least test parts which touched keyboard directly, since the 0.11.0 release, maybe it's simpler than I think in the end of the day.

[pbgc]

@kchibisov ok. If you need help testing/compare something just say.
(I have a MBP 16inch 2021 (M1 Pro) with Portuguese layout and have 0 problems)

[kchibisov]

I also have macbook and I've tested with japanese IME, chinese IME, korean IME, some other layots, ABC layout, dvorak layout, and I don't have any of the mentioned issues here.

The logs here confirmed that we don't get any keyboard input at all from our windowing library, so it's lost somewhere...

I know that the issue might go away entirely with 0.13.0 version, because upstream library will change the entire keyboard input, but there's no ETA.

[pbgc]

@kchibisov what really puzzles me is, for the persons having the prob, that if alacritty is launched from terminal it works! It's doesn't work when launched from the Dock or Spotlight ..

[gzm55]

I also have macbook and I've tested with japanese IME, chinese IME, korean IME, some other layots, ABC layout, dvorak layout, and I don't have any of the mentioned issues here.

could you plz test these two IME?

• has problem: https://im.logcg.com/loginputmac3
• no problem: https://pinyin.sogou.com/mac/

[kchibisov]

has problem: https://im.logcg.com/loginputmac3

I won't install software I have no way of understanding, sorry. It must be something open source or builtin apple solution.

[mrtolkien]

I have a similar issue and behaviour is super weird. I'm using Alacritty 0.12 on Mac OS.

• When I open alacritty (U.S. input method):
  • Works: Enter, Ctrl+L, Ctrl+D
  • Doesn't work: Text input
• Once I switch input methods, everything works
  • I need to switch and type at least one other character with another input method then come back to US
• If I select another window and come back to Alacritty, we're back to the first situation

I have no clue what's happening and this behaviour is puzzling to say the least.

[juse-less]

For those text input in Alacritty works for, do you have more than one input method?

I only have one keyboard layout, but do have Fig and its input method (for the completion popup).
Whenever I uninstall the Fig input method, Alacritty works.
When I re-install it, it breaks again.
For uninstalling I need to restart Alacritty, but when installing the Fig input method it breaks immediately.
It's still temporarily resolved by changing keyboard layout, as others have mentioned.

Edit:
Alacritty v0.11.0 works for me, but Alacritty v0.12.0-rc1 does not.

I've tested on both an intel 2019 MacBook Pro, and an M1 2022 MacBook Pro, if that'd matter.
Both are on macOS Ventura.

Edit 2:
After a bisect, 1c878a0 is the commit where it starts breaking for me.

Edit 3:
I tried bisecting both winit and Alacritty alongside each other, to try and get a rough pointer on where it happens.
As the commit message in my 2nd edit is an update to winit 0.28.0, that's what I picked as a bad commit.

Eventually I got to the rust-windowing/winit@3fd7384 commit, where it started breaking again.
Reverting this line, specifically, it starts working again.
With the other change/added line in that commit, it still works.
This was also tested against Alacrittys latest master, which works with that line reverted.

That's about as helpful as I could possibly be, unfortunately, as I'm not super-familiar in this area, nor fluent in Rust.

[kola-web]

Computer : Mac M1
Input method: rime
Recovery method: enter neovim in normal mode, switch to Chinese input method and press some keys, then click esc key, then alacritty input will not work

[juse-less]

I've done some more testing.

Irrespective of layout I've tested (US, US International, British, Canadian, Finnish, Swedish, Norwegian, German, ...), using special characters like ´, ¨, ~ will make it possible to type anything again.
So I don't need to switch layouts, or so - just tap one of them and all keys are again available for me.

I only ever have a single layout added at a time, but always with Figs input method installed.
All of them works correctly if I uninstall the Fig input method.
Contrary to what I mentioned before, I do have to restart Alacritty after re-installing Figs input method.

---

Rust, developing terminals, IME, etc, isn't really my cup of tea [yet], but I tried poking around the code a bit, testing things.

I wrote down the things I tested, if it's of use to anyone

Steps I used to install and compile things on macOS

I clone both winit and Alacritty, alongside each other.
I then switch the winit reference in both alacritty/alacritty/Cargo.toml and alacritty/alacritty_config/Cargo.toml from

winit = { version = "0.28.2", default-features = false, features = ["serde"] }

to

winit = { path = "../../winit", default-features = false, features = ["serde"] }

Then do the changes I'd like to test, and follow the manual installation instructions outlined here.
Which really is just running make app in the alacritty directory.
To clean up between each test, I use make clean, then make app again.
The compiled app can be found inside the alacritty/target/release/osx directory.

What I tested

Because these two lines ([1](https://github.com/alacritty/alacritty/blob/ead65221ebe06ff5689e65b866d735d4365d0e9e/alacritty/src/display/window.rs#L176), [2](https://github.com/alacritty/alacritty/blob/ead65221ebe06ff5689e65b866d735d4365d0e9e/alacritty/src/display/window.rs#L179)) were added in the Alacritty [commit I linked above](https://github.com//issues/6817#issuecomment-1510439015), I tried commenting them out. But it still didn't work.

While this line wasn't changed in that commit, I tested to disable IME by setting it to false.
That did make it work.

There's no doubt it's about IME, which is why I was poking around the relevant lines linked above.
But nothing I do in Alacritty itself seems to fix it.

Back to winit, I proceeded to revert this line again.
While far-fetched in this case, I've seen some weird stuff before..
So I tried calling self.hasMarkedText() before the loop, to ensure it's not something being done in that function.
That does make it work, as one would expect.

Snippet used

self.hasMarkedText();

// Commit only if we have marked text.
if self.is_ime_enabled() && !is_control {
    self.queue_event(WindowEvent::Ime(Ime::Preedit(String::new(), None)));
    self.queue_event(WindowEvent::Ime(Ime::Commit(string)));
    self.state.ime_state = ImeState::Commited;
}

I'm not sure if text should be marked at this stage, or not (or what it means).
Or why it's considered marked when starting Alacritty from another terminal.

[brunoabreu]

Hey @juse-less, I was also debugging this issue, despite not being a "rustacean" either. I think you're on point with your findings.

I opened an issue in the winit project. Let's see how it unfolds.

[kchibisov]

Could someone test this tree git clone https://github.com/kchibisov/alacritty -b macos-ime. I can't repro myself and don't want to register with fig.

[juse-less]

@kchibisov That works for me, using Figs input method. 👍

I've also tested with various different layouts/input sources - British, Finnish, German, Swedish, US.
Both 'alone' and while having many input sources added at once.

I restarted Alacritty in-between tests.

[kchibisov]

I'd assume you've tested the running it from the .app file?

[juse-less]

Yeah. Sorry.
I copied your exact git clone command, then ran make app inside the directory.
Then proceeded to run the generated app (target/release/osx/Alacritty.app).
I started it from Finder, and not another terminal or so.

[kchibisov]

The 0.12.1 having a fix for that was released. If the issue is still present let me know in a separate issue.