This happens for me as well, but it's seemingly random keys being "pressed", including "f" and various modifiers such as "Alt". It only seems to happen in GUI applications under Crostini, never in the terminal itself.

xev seems to be the most reliable application for reproducing the issue right away though, by just running it and watching the input stream in until something is pressed.

Google Chrome	70.0.3538.22 (Official Build) beta (64-bit)
Revision	ac9418ba9c3bd7f6baaffa0b055dfe147e0f8364-refs/branch-heads/3538@{#468}
Platform	11021.19.0 (Official Build) beta-channel cyan
Firmware Version	Google_Cyan.7287.57.180
Acer R11

I've also seen this with miscellaneous other keypresses, since I originally filed this bug. It's been fairly consistently recurring, although not 100% of the time -- at the moment, for instant, I can't reproduce it at all.

Happens to me too in applications that are GUI. GImp, Inkscape very annoying to the point where it just ruins what I do there.

@strom.anders and @nelhage -- can you please file feedback (alt+shift+i) and include "#crostini-xev" in the description? That'll let us look at the logs to see what's going on. This should have been fixed with  Issue 847500  but maybe we missed some cases.

Posted a feedback report. Tagged it #crostini-xev and linked this issue.

When I got home to my pixelbook today I was initially unable to reproduce, but after a while working it presently reproduces fairly reliably. It's presently spamming "T" or Left_Tab, but this varies over time.

It recurs even if I switch away from xev by clicking on a different window, and then click on xev in the launcher to get back -- without pressing any keys --, so I don't think it's a trivial case of "depressed key gets stuck"

I also experiencing the same issue. I'm able to consistently reproduce the issue by switching X11 and host window back and forth for a number of times. Honestly speaking, it has been really annoying... No such spurious key press when I stay at the same window.

This seems to be happening less frequently in 70.0.3538.58 on the Beta channel (Acer R11). Is that just a fluke, or is anyone else experiencing the same thing after upgrading?

After typing the comment above and tabbing back to one of my Linux GUI apps, the "t" key of course started repeating, so it's still happening. :)

I'm seeing the same behavior. It's gotten rarer, but still occurs occasionally. It seems to be "sticky"; when it's happening, it happens even in repeated experiments, but it also sometimes stops and stops for hours or days.

Jeff, can you repro?

After further studying with xev, these are the keycodes that seem to be triggered for me:

29 33 45 64 37

Disabling repeat for all of them through e.g. "xset -r 29" does seem to stop the issue apart from the initial keypress, but this is obviously not a viable workaround long-term (perhaps I *do* want those keys to repeat at some point). ;)

As a side note, this doesn't happen when running Crouton on the same machine. It also never happens when running terminal applications through the Terminal (I've typed tens of thousands of words into Vim without a single occurrence of the issue).

The issue only seems to manifest when running GUI apps through Crostini. 

Keycode 59 seems to show up quite a bit as well.

 Issue 863713  has been merged into this issue.

I have not been able to reproduce this yet. If anyone can provide tips for reproducing it, that'd be super helpful.

It happens quite often to me and apparently at random I haven't been able to isolate any particular trigger. I'll update if I can find anything.

I was able to perform one experiment: when it's happening, it still happens with `env - xev -d :0`, so I don't think it's tied to any environment variables I have (I set XMODIFIERS and some miscellaneous other crap, and that might explain why it's localized to certain users).

If there are any additional logs I can collect when it occurs I'm more than happy to do so.

I am in a similar situation where I can't pinpoint a trigger, but it does happen quite regularly. I can probably either give you temporary access to my Pixelbook or I might be able to come to an Google office with my device (prefer SFO, but MTV is doable). Let me know, if any of that would be of help.

Also happens to me often while using Android studio inputting random characters including spaces and tabs or opening windows using shortcuts.
Version 71.0.3578.21 
will send feedback using the tag

Feedback reports won't really tell me anything useful for this particular bug.

I do have some other questions that may help:

1. When the repeating key is occurring, and you run xev, is it just printing out an endless sequence of KeyPressed / KeyReleased events? I wouldn't mind getting a copy/paste of a couple of those too in case there's something else interesting in the data.

2. When the repeating key is occurring, if you press/release that key...does it end the repeating?

Yes, and yes to the above. I've currently xset -r'ed out all offending keys as mentioned above, so currently there's only one offending keypress that I've got to deal with and the 'xev' output wouldn't be of much use unless I clear out the setup again (it's worst if it's Alt or Control since you never know which action an app will take when you push a letter together with Alt or Control).

What you said about Alt/Control is interesting....because if I run xev and hold Alt or Ctrl then the keys don't repeat. It just prints out a singular press/release pair (unlike most other keys which'll will spew that out continually).

Do you see the same behavior as me for Alt/Ctrl with xev?

It doesn't matter if Alt/Ctrl are (visibly) repeated in xev - if they're held, they will affect the next key pressed. :)

But I don't believe that I ever saw them visibly repeated in xev, if that's of any help. So that seems to match the behavior of holding the key down, not repeating it quickly.

Yeah, I know...but if they were visibly repeated in xev...then that'd tell me that maybe whatever environment changes you made which is causing that could be the lead I'm looking for. :)

And if Alt/Ctrl get stuck (and it's not an endless repeat in xev)...does pressing Alt/Ctrl to stop the repeating generate just a KeyRelease in xev or does it generate a KeyPress/KeyRelease?

Just trying to find something else odd to grasp onto in order to look into this more or be able to reproduce it.

I can at least confirm that pressing the offending key always stopped it from repeating/being interpreted as held down, even with Alt/Ctrl. After that point, it wouldn't reoccur until switching away from and back to a GUI app running under Crostini (by keyboard or mouse, so no actual key presses had to be involved).

It also happened if a new window within the app was opened (e.g. a Preferences dialogue, or an Open/Save dialogue).

One other valuable data point is whether this happens in Wayland apps too.

Can you also check something like gedit to see if it happens in there too?

All the other apps mentioned in the bug (xev, gimp, inkscape, emacs) are all X11 apps.

Actually, when you mention it, I never had it happen in Gedit. It could be a fluke, but I cannot confirm. Hopefully someone else will chime in as well.

If everything else fails and you're not getting further input, drop me an e-mail and I'll do a powerwash and figure out a way to share my screen with you as I run xev and some select apps a couple of times.

Here's some `xev` spew whilst it's happening:

KeyRelease event, serial 35, synthetic NO, window 0xc00001,
    root 0x350, subw 0x0, time 657124578, (-544,-86), root:(700,713),
    state 0x4, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) " "
    XFilterEvent returns: False

KeyPress event, serial 35, synthetic NO, window 0xc00001,
    root 0x350, subw 0x0, time 657124578, (-544,-86), root:(700,713),
    state 0x4, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) " "
    XmbLookupString gives 1 bytes: (09) "       "
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0xc00001,
    root 0x350, subw 0x0, time 657124603, (-544,-86), root:(700,713),
    state 0x4, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) " "
    XFilterEvent returns: False

KeyPress event, serial 35, synthetic NO, window 0xc00001,
    root 0x350, subw 0x0, time 657124603, (-544,-86), root:(700,713),
    state 0x4, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) " "
    XmbLookupString gives 1 bytes: (09) "       "
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0xc00001,
    root 0x350, subw 0x0, time 657124629, (-544,-86), root:(700,713),
    state 0x4, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) " "
    XFilterEvent returns: False

KeyPress event, serial 35, synthetic NO, window 0xc00001,
    root 0x350, subw 0x0, time 657124629, (-544,-86), root:(700,713),
    state 0x4, keycode 23 (keysym 0xff09, Tab), same_screen YES,
    XLookupString gives 1 bytes: (09) " "
    XmbLookupString gives 1 bytes: (09) "       "
    XFilterEvent returns: False

Pressing *any* non-modifier key makes it stop; Both "Tab" [in the case of the above] and any other character, like "x". Holding modifier keys adds them to the input events, but doesn't stop the repeating.

As of this writing, this repeats materialize virtually every time I run `xev`, but have not shown up in `gedit` after perhaps half a dozen instances of open and switching windows back and forth.

So that confirms it's only in X11 apps and not in Wayland apps. 

It's also interesting that in the repeated keypresses you have there, that the Ctrl key is also apparently being registered as being held down at the same time (state 0x4).  Is the state always nonzero when the phantom keypresses occur?

(sorry for all the back and forth, but without being able to reproduce it I want to get all the details I can to figure out where the breakage would be...and that may also help with reproduction too)

State is not always nonzero.

Here's another recent spew:

KeyPress event, serial 35, synthetic NO, window 0x400001,
    root 0x350, subw 0x0, time 80594350, (173,127), root:(1417,926),
    state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (72) "r"
    XmbLookupString gives 1 bytes: (72) "r"
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x400001,
    root 0x350, subw 0x0, time 80594376, (173,127), root:(1417,926),
    state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (72) "r"
    XFilterEvent returns: False

KeyPress event, serial 35, synthetic NO, window 0x400001,
    root 0x350, subw 0x0, time 80594376, (173,127), root:(1417,926),
    state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (72) "r"
    XmbLookupString gives 1 bytes: (72) "r"
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x400001,
    root 0x350, subw 0x0, time 80594402, (173,127), root:(1417,926),
    state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (72) "r"
    XFilterEvent returns: False

KeyPress event, serial 35, synthetic NO, window 0x400001,
    root 0x350, subw 0x0, time 80594402, (173,127), root:(1417,926),
    state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (72) "r"
    XmbLookupString gives 1 bytes: (72) "r"
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x400001,
    root 0x350, subw 0x0, time 80594427, (173,127), root:(1417,926),
    state 0x0, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (72) "r"
    XFilterEvent returns: False

As I press and release modifiers while that's spewing, state changes to reflect them, but it doesn't stop the spew.

OK, thanks. There was also some mention before that maybe custom environment settings might be required in order for this to be reproduced (although I know you did a test that reset the environment for xev...but that wouldn't reset the environment for XWayland/sommelier).

Can you post what the env is for the running xwayland and sommelier (with the -X argument) processes on your system?

root@penguin:/home/nelhage# ps -ww $(pgrep -f Xwayland)
  PID TTY      STAT   TIME COMMAND
  115 ?        Sl     0:00 /opt/google/cros-containers/bin/../lib/ld-linux-x86-64.so.2 --library-path /opt/google/cros-containers/bin/../lib --inhibit-rpath  /opt/google/cros-containers/bin/Xwayland.elf -nolisten tcp -rootless -shm -displayfd 20 -wm 21
root@penguin:/home/nelhage# xargs -0 -n1 < /proc/115/environ
USER=nelhage
HOME=/home/nelhage
SOMMELIER_VERSION=0.20
MANAGERPID=92
NOTIFY_SOCKET=/run/user/1000/systemd/notify
WAYLAND_DISPLAY=.
LOGNAME=nelhage
WAYLAND_SOCKET=22
JOURNAL_STREAM=8:494
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
INVOCATION_ID=d70191c3a1014cb4a00343b63f105340
XDG_RUNTIME_DIR=/run/user/1000
LANG=en_US.UTF-8
SOMMELIER_FRAME_COLOR=#F2F2F2
SHELL=/bin/bash
SOMMELIER_ACCELERATORS=Super_L
PWD=/home/nelhage
root@penguin:/home/nelhage# ps -ww $(pgrep -f somm)
  PID TTY      STAT   TIME COMMAND
   97 ?        Ss     0:00 /opt/google/cros-containers/bin/../lib/ld-linux-x86-64.so.2 --library-path /opt/google/cros-containers/bin/../lib --inhibit-rpath  /usr/bin/sommelier.elf -X --x-display=0 --sd-notify=READY=1 --no-exit-with-child /bin/sh -c systemctl --user import-environment DISPLAY XCURSOR_SIZE SOMMELIER_VERSION; . /etc/sommelierrc
  100 ?        Ss     0:00 /opt/google/cros-containers/bin/../lib/ld-linux-x86-64.so.2 --library-path /opt/google/cros-containers/bin/../lib --inhibit-rpath  /usr/bin/sommelier.elf --master --sd-notify=READY=1 --socket=wayland-0 /bin/sh -c systemctl --user import-environment WAYLAND_DISPLAY SOMMELIER_VERSION
root@penguin:/home/nelhage# xargs -0 -n1 < /proc/97/environ
USER=nelhage
HOME=/home/nelhage
MANAGERPID=92
NOTIFY_SOCKET=/run/user/1000/systemd/notify
LOGNAME=nelhage
JOURNAL_STREAM=8:494
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
INVOCATION_ID=d70191c3a1014cb4a00343b63f105340
XDG_RUNTIME_DIR=/run/user/1000
LANG=en_US.UTF-8
SOMMELIER_FRAME_COLOR=#F2F2F2
SHELL=/bin/bash
SOMMELIER_ACCELERATORS=Super_L
PWD=/home/nelhage

Nothing different there than on my setup (except I have some newer vars due to having a more recent development version)...but those shouldn't affect the bug.

I just created a fresh VM and container, and the problem recurred immediately. Console log attached.

I think that should hopefully rule out any environment differences inside the VM.

Note that this problem has recurred to me across a powerwash of the host and across multiple VMs, so it's weird to me it doesn't reproduce.

Deleted: xev.log 9.8 KB

xev.log 9.8 KB View Download

Thanks! What device did you do that on?  I actually just reproduced it twice here when I setup brand new VMs on two different devices...both were ARM devices though. (and your original post mentioned eve, so I'm assuming you're on a Pixelbook)

Yeah, I'm on a pixelbook.

 Issue 892961  has been merged into this issue.

Just for reference, this is still happening in 71.0.3578.49 (beta) cleanly installed.

Duplicate  https://crbug.com/901838  ?

 Issue 901838  has been merged into this issue.

 Issue 910155  has been merged into this issue.

I got some more details back from a version with extra logging that I sent to someone who could reproduce this. Apparently when the app starts up, and we get the first wl_keyboard_enter call coming from the Chrome compositor, it's indicating that a key is being held down.  I'm guessing that Wayland apps just handle this type of thing differently than X11 apps, which is why it only manifests in X11 apps.  I'll look into what's happening in exo relating to this to see if I can find some other lead to debug there.

Can anybody confirm/deny that they are using the ComposeKey input method? (turning it off doesn't mean it'll fix the problem, unless you reboot after that)

That's my current hunch...and I also just reproduced the problem after installing that and turning it on.

Yes, I can confirm I'm using it.

That's 3 for 3 so far (2 other internal users confirmed it).  I'm declaring ComposeKeys as the cause of the problem now.

I've filed a bug with that project here in case anybody wants to add comments to it:

https://github.com/google/extra-keyboards-for-chrome-os/issues/46

Is the ComposeKeys extension the built-in feature for switching between the various pre-installed language keyboard layouts? 

Because this exact issue is plaguing every Chromebook I use across many powerwashes. I have not installed any extra keyboards and am just using the US and Icelandic keyboard layouts. I don't use a compose key with either keyboard, just use the Icelandic one as normal.

If ComposeKey === using an international keyboard, then I can confirm that it is, indeed, the cause of the problem on my machines. If I stick to the US keyboard layout from boot, the problem does not occur. Otherwise, usually as soon as I have switched keyboard layouts, typed something and then switch to a linux app, it happens often enough to almost make the machines unusable.

I have this issue without using the compose key extension or an international layout, but I am using a custom remap extension with chrome.input.ime.

OK, looks like I jumped the gun then on assigning blame to that extension. It's probably somewhere else in the stack then; and at least I should be able to track down where now that I can reproduce it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/23e30de532011d1bed9ec8d4615f3590d3e180d3

commit 23e30de532011d1bed9ec8d4615f3590d3e180d3
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Wed Dec 12 22:24:04 2018

exo: Fix stuck keys with wayland clients

Remove a key from the pressed keys map in the DidProcessEvent call as
in addition to the existing removal in OnKeyEvent. When IME is
active, then sometimes DidProcessEvent gets invoked before OnKeyEvent,
and when that happens we end up with a stuck key in the pressed keys
map.

Bug:  840155 
Test: exo_unitests --gtest_filter=SeatTest.PressedKeys
Change-Id: I54bbaaeb5656b4ece8cd10f8b5f7065ddad33813
Reviewed-on: https://chromium-review.googlesource.com/c/1373010
Commit-Queue: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Reviewed-by: David Reveman <reveman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616084}
[modify] https://crrev.com/23e30de532011d1bed9ec8d4615f3590d3e180d3/components/exo/seat.cc
[modify] https://crrev.com/23e30de532011d1bed9ec8d4615f3590d3e180d3/components/exo/seat_unittest.cc

The fix wasn't IME specific...but I had to use it to reproduce it all...and I can no longer repro after the fix I've done. Hopefully this'll take care of all the cases, based on the code it seems reasonable it would. It should show up in the next dev channel release.

It already in dev? I still got this problem on my pixelbook

It should be in the first dev channel release for M73..I don't believe we've put one out yet.

 Issue 915248  has been merged into this issue.