Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Console UI does not update unless there is keyboard/mouse input #171

Open
Adam-Gleave opened this issue Oct 7, 2021 · 8 comments
Open
Labels
C-console Crate: console. E-needs-mcve Effort: this bug needs a minimal complete and verifiable example. S-bug Severity: bug

Comments

@Adam-Gleave
Copy link
Contributor

Hi, I've noticed a bit of a weird issue with the UI. Locally, everything seems to work fine, but when running console in an ssh session, all that gets displayed is a blinking cursor until there is some form of input. If I wiggle the mouse a little bit, or press something on the keyboard, the display gets updated, otherwise it remains unresponsive. Once the console is running, it seems to freeze after interacting with it (with the arrow keys for example), and doesn't update the UI again.

I've tried adding a println! at the first line of the main function to see if it's something to do with tui, but I also don't see that until I make some form of input.

Unfortunately I'm not sure what other details to share, other than that it only appears when running under an ssh session -- sorry I can't be a little more specific.

@hawkw
Copy link
Member

hawkw commented Oct 7, 2021

Hmm, well, this is certainly weird! Thanks for the report.

One thing that might be worth trying is running tui's example programs in a ssh session and seeing if you get the same behavior?

In particular, tui has a demo app for all of the backends it supports: crossterm_demo.rs, curses_demo.rs, rustbox_demo.rs, and termion_demo.rs. It might be worth trying to run all of those and seeing if you can reproduce the issue with any of them?

It's certainly possible that this is something in the console rather than in tui, but it seems like it's worth trying to completely isolate all the variables...

@hawkw
Copy link
Member

hawkw commented Oct 7, 2021

It could also be useful to know details about the version of ssh you're running (on the client and on the host). You can get the ssh client version with ssh -V. I'm not sure how to figure out the sshd version on the host off the top of my head; the best way might just be to query the package manager on the host or something...

@hawkw hawkw added C-console Crate: console. E-needs-mcve Effort: this bug needs a minimal complete and verifiable example. S-bug Severity: bug labels Oct 7, 2021
@hawkw
Copy link
Member

hawkw commented Oct 7, 2021

Testing this out on two of my machines, I can't seem to reproduce this; if I connect over ssh and run the console, everything works normally, and keyboard input doesn't cause the console to hang.

My guess, then, is that this is related to some combination of

  • the specific ssh client
  • the specific sshd on the host
  • the particular flags passed to the ssh command
  • the terminal emulator you're using

I'm not sure which of those factors could be significant here, but it could be useful to know all of them.

In my attempt to reproduce:

  • the ssh client version is
    :; ssh -V
    OpenSSH_8.4p1, LibreSSL 3.1.5
  • the sshd version on the host was
    :; sshd -V
    unknown option -- V
    OpenSSH_8.7p1, OpenSSL 1.1.1l  24 Aug 2021
  • the ssh command was just
    :; ssh eliza@"$HOST_IP"
  • and the terminal emulator on the client is
    :; home-manager packages | rg alacritty
    alacritty-0.7.2-terminfo
    alacritty-0.7.2

It could be useful to know the specifics of your configuration so we can compare notes?

@Adam-Gleave
Copy link
Contributor Author

Sure! If I repeat those same commands:

  • ssh client version
:~# ssh -V
Open7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019
  • sshd version gives me the same output as above (with sshd -V), and querying the package manager returns Unable to locate package sshd...This could be me being silly though. All ssh-related packages I can find on the machine list Open7.9p1 in their version.

  • ssh command

ssh -l root "IP_ADDR"

And I am using iTerm2 on the client system.

I will try out those example tui programs today and get back to you.

@hawkw
Copy link
Member

hawkw commented Oct 8, 2021

Okay, thanks for the info! Another thing that might be worth trying is switching to a different terminal on the client. Since you're presumably on a Mac (because you're using iTerm2), it might be worth trying to see if the issue is reproducible with Terminal.app?

@Adam-Gleave
Copy link
Contributor Author

Apologies for the wait -- always too many things going on! I've just tried out the four tui examples that you suggested, and everything seems to be working fine with them, with no need for additional input.

We also observe the same behaviour using Terminal, too.

@hawkw
Copy link
Member

hawkw commented Oct 13, 2021

Interesting, thanks for the update. I can't immediately think of anything that would be different between the console and tui's example programs, that's very strange.

@hawkw
Copy link
Member

hawkw commented Dec 17, 2021

Can I get you to try out PR #222 and see if you still have this issue? Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-console Crate: console. E-needs-mcve Effort: this bug needs a minimal complete and verifiable example. S-bug Severity: bug
Projects
None yet
Development

No branches or pull requests

2 participants