alacritty: Blocking paste freezing Alacritty

Issue

I’m on Gentoo, running Sway (and thus Wayland.) The clipboard has never really worked on Wayland, it’s consistently a mess. Talks with @chrisduerr and @cmr suggested that it should be fixed on master.

Today I compiled master with rustc 1.34.2 to try, and it seems like it is still not working.

How to reproduce

  1. Running Sway (might work on other Wayland WMs?)
  2. Open Firefox with GDK_BACKEND=wayland set.
  3. Select and copy some text on Firefox.
  4. Switch to another workspace where Alacritty is.
  5. Paste text (ctrl+shift+v)

The result should be a freeze and eventually a crash.

On a release build I get this:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: EventsLoopClosed', src/libcore/result.rs:997:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

On a debug build with backtracing I get this:

alacritty on  master via 𝗥 v1.34.2 [I] ➜ RUST_BACKTRACE=1 cr
   Compiling alacritty v0.3.2 (/home/bemeurer/src/alacritty/alacritty)
    Finished dev [unoptimized + debuginfo] target(s) in 7.18s
     Running `target/debug/alacritty`
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: EventsLoopClosed', src/libcore/result.rs:997:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:70
             at src/libstd/sys_common/backtrace.rs:58
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: rust_begin_unwind
             at src/libstd/panicking.rs:312
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::result::unwrap_failed
             at /var/tmp/portage/dev-lang/rust-1.34.2/work/rustc-1.34.2-src/src/libcore/macros.rs:17
   9: <core::result::Result<T, E>>::unwrap
             at /var/tmp/portage/dev-lang/rust-1.34.2/work/rustc-1.34.2-src/src/libcore/result.rs:798
  10: winit::platform::platform::wayland::keyboard::init_keyboard::{{closure}}
             at /home/bemeurer/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.19.1/src/platform/linux/wayland/keyboard.rs:111
  11: smithay_client_toolkit::keyboard::implement_kbd::{{closure}}::{{closure}}::{{closure}}
             at /home/bemeurer/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.5/src/keyboard/mod.rs:720


^C

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 3
  • Comments: 26 (19 by maintainers)

Commits related to this issue

Most upvoted comments

I’d say the issue was likely that FF was blocking to return the clipboard data and Alacritty reads the clipboard data synchronously in the main thread, leading to all blockages directly propagating to Alacritty.

This was already showing up with the empty clipboard previously, though that has been fixed in the Wayland library to resolve immediately.

I think it’s worth to keep this issue around to track this problem, because I don’t think Alacritty should crap itself, regardless of what the application at the other end of the clipboard is doing.

This has suddenly started to happen to me today. So far I have had zero problems with the clipboard with alacritty on wayland. I didn’t upgrade or anything, just started to happen out of nowhere.

@physkets can you run with the env variable WAYLAND_DEBUG=1

That would be more descriptive of the error then RUST_BACKTRACE due to it being a wayland event loop issue

Just FYI, if you’re on a modern-ish version of firefox, the environment variable to enable wayland is MOZ_ENABLE_WAYLAND=1 and it kinda ignores GTK_PLATFORM.

Someone else will know far better than I do, but I find killing Xwayland to be pretty useful in making sure that something isn’t running under Xwayland that you think should be running natively.

What commit is that?

Should be https://github.com/jwilm/alacritty/commit/9e89aaa477369b20a06f4b9f636d7fd543c4c985.

Additionally, can you see if installing wl-clipboard solves your issue? While not ideal – installing a package for cross-client clipboard support – it’s the best Wayland has, at the moment. I currently use that and haven’t had any problems with copying and pasting between Firefox and Alacritty.