jless crashes when using mouse interactions after running docker compose

[zzh1996]

I encountered an issue with jless where it crashes when I use mouse interactions (clicking or scrolling) after having executed the docker compose command in the terminal. Below are the details:

Steps to Reproduce:

1. Open a terminal.
2. Run docker compose up in a directory with docker-compose.yml provided below. (docker compose should be V2.)

services:
  test:
    image: ubuntu:latest

3. After the command completes, run curl https://api.github.com/repos/PaulJuliusMartinez/jless/commits -o commits.json.
4. Run jless commits.json.
5. Try clicking or scrolling within jless.

Expected Behavior:

jless should function normally without crashing.

Actual Behavior:

jless crashes upon using the mouse for clicking or scrolling.

Environment:

• Terminal Emulators:
  • iTerm2 3.5.0
  • macOS 14.5 built-in terminal
• Versions:
  • docker compose version: Docker Compose version v2.27.0-desktop.2
  • jless version: jless 0.9.0 (installed via brew)

Additional Information:

• The issue is reproducible across different terminal emulators.
• It doesn't seem related to environment variables or the shell being used (zsh or bash).
• Programs such as htop and vim work normally when using mouse interactions after running docker compose.

I have attached an asciinema recording showcasing the issue.

https://asciinema.org/a/WatTzwyRfqAWPqBykN6yyr0CA

Error message:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/index.crates.io-6f17d22bba15001f/termion-1.5.6/src/event.rs:199:29
stack backtrace:
   0:        0x1022a8238 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he69c0e17cb41f255
   1:        0x1022cd5eb - core::fmt::write::h66293df4c7dd941a
   2:        0x102287a56 - std::io::Write::write_fmt::h2f5a7ea5f48a0b56
   3:        0x1022a8000 - std::sys_common::backtrace::print::h71fd332624ce1826
   4:        0x1022a8f55 - std::panicking::default_hook::{{closure}}::ha2a0e70fb3678142
   5:        0x1022a8cd1 - std::panicking::default_hook::hb166cd42dec7ff92
   6:        0x1022a9518 - std::panicking::rust_panic_with_hook::h2b924837648ff0c0
   7:        0x1022a9412 - std::panicking::begin_panic_handler::{{closure}}::h04e24a68d30d9f5c
   8:        0x1022a8469 - std::sys_common::backtrace::__rust_end_short_backtrace::hd45b5152c8265971
   9:        0x1022a91cd - _rust_begin_unwind
  10:        0x1022da7d3 - core::panicking::panic_fmt::h9302663e63786640
  11:        0x1022da85e - core::panicking::panic::hc241fa596ee7b5bf
  12:        0x10216f5f4 - termion::event::parse_csi::h1709409a441283d0
  13:        0x102170446 - jless::input::TuiInput::get_event_from_buffered_input::h7f0fba804f003d22
  14:        0x102170976 - <jless::input::TuiInput as core::iter::traits::iterator::Iterator>::next::hdef361545a2dadad
  15:        0x102145c24 - jless::app::App::run::hae1b7190ed3f5cf3
  16:        0x10213c51d - jless::main::ha5528f325379956b
  17:        0x102178816 - std::sys_common::backtrace::__rust_begin_short_backtrace::hf374a4127f440e46
  18:        0x10217b56c - std::rt::lang_start::{{closure}}::h474d26d9797e8a23
  19:        0x1022a90b4 - std::panicking::try::hb5cb29dbfee1dcfc
  20:        0x10229074e - std::rt::lang_start_internal::h634e63ff6023f727
  21:        0x10213cc2c - _main
  22:     0x7ff80a883366 - <unknown>

[PaulJuliusMartinez]

I am unable to reproduce (though I am running a different version of docker compose up).

Can you paste the output of stty -a before and after running docker compose up?

[zzh1996]

I am unable to reproduce (though I am running a different version of docker compose up).

Can you paste the output of stty -a before and after running docker compose up?

Before:

speed 38400 baud; rows 25; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; status = ^T; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
ixany imaxbel iutf8
opost -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl
echoke -flusho -extproc

After:

speed 38400 baud; rows 25; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; discard = ^O; status = ^T; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
ixany imaxbel iutf8
opost -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig icanon -iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl
echoke -flusho -extproc

Although the outputs of these two stty -a commands are not identical, setting the tty state to match the latter manually using the stty command does not trigger the previously mentioned bug.

Additionally, docker compose up does not change the "Terminal State" displayed by iTerm2.

I have researched these aspects before, and I still haven't figured out what exactly docker compose up changes in the terminal / tty state.

[PaulJuliusMartinez]

Hmm, what if you use stty to update the state to what it was prior to running docker compose up, then does jless still crash?

A few more ideas:

• If you run reset after running docker compose up, does that fix it? (I hope so.)
• If, after running docker compose up, you run jless and don't use your mouse, then exit and then run jless again, does that fix it? I.e., does jless's shutdown behavior fix the problem?
• Are there any other commands/scripts you've found that you can run in between docker compose up and jless that fix it?

[zzh1996]

Hmm, what if you use stty to update the state to what it was prior to running docker compose up, then does jless still crash?

Still crash.

A few more ideas:

• If you run reset after running docker compose up, does that fix it? (I hope so.)

Unfortunately, no. (both iTerm2 and Terminal)

• If, after running docker compose up, you run jless and don't use your mouse, then exit and then run jless again, does that fix it? I.e., does jless's shutdown behavior fix the problem?

No.

• Are there any other commands/scripts you've found that you can run in between docker compose up and jless that fix it?

I did not find such a command. This is exactly the point of my curiosity. I really want to know what state docker compose up actually modifies. If I could figure out the specific reason myself, I would directly state the more specific reason in the issue instead of just mentioning the docker compose up command.

Additionally, I'm not familiar with Rust. Would you be willing to help me temporarily create a branch and modify the code to collect the raw data that jless receives from the terminal for debugging purposes? If so, I can help you run it and collect the data.