Paste functionality uses old, cached values

[jayache80]

I use Alacritty on Wayland, specifically with the Sway window manager. Alacritty uses this underlying library to handle text copying and pasting. When pasting text from the clipboard with Alacritty (using default Ctrl+Shift+V key binding) the pasted text will actually be older, previously copied text. Pasting again will eventually paste the most recently copied text, however it may take several repetitions before it "bubbles" up.

This only seems to occur on a very long running Alacritty instance. For example, I have several Alacritty instances open, and the recently started processes do not exhibit this issue, but a very old instance does exhibit this behavior and continues to do so.

Steps to reproduce:

1. Start Alacritty and use the same instance over the course of many days.
2. Copy text to clipboard using any means (other applications that have access to Wayland clipboard or Alacritty itself)
3. Paste text using Alacritty. The pasted text will incorrectly be previously copied text. Subsequent pastes will eventually paste the most recently copied text.

Example:

• Copy "foo" from text using some application.
• In Alacritty at a shell, execute a Paste hot key (Ctrl+Shift+V by default)
• "foo" should be output to the screen. If it isn't, it may be "queued up". Keep retrying the Paste operation until "foo" is outputted.
• Copy "bar" from text using some application.
• Repeat Paste hot key an arbitrary amount of times. Alacritty will output "foo" each time until eventually "bar" is output

Note: In the above, "some application" can be anything that is able to copy text to the Wayland clipboard. The above example occurs for both copying using Alacritty's highlighting and Ctrl+Shift+C, or copying text in Firefox.

Here is a Youtube video I created which demonstrates the issue:

[chrisduerr]

Similar things seem to occur on X11: alacritty/alacritty#3601

Note: In the above, "some application" can be anything that is able to copy text to the Wayland clipboard.

Does this also happen when copying from Alacritty to Alacritty, within the same instance?

[jayache80]

Similar things seem to occur on X11: alacritty/alacritty#3601

Ah, darn. I searched but didn't find this existing issue. I had figured the issue is in this underlying copy/paste issue library but truth be told I haven't found a data structure here that has this "queuing" behavior, so perhaps the issue truly is in the Alacritty application itself.

Does this also happen when copying from Alacritty to Alacritty, within the same instance?

Yes. The video demonstrates 3 ways of copying text:

1. From an "outside" Wayland application (Firefox)
2. From the same Alacritty instance.
3. From a different Alacritty instance.

The video demonstrates case 2 when copying and pasting "bar". Sorry it's a little long-winded; it's a little less painful to watch if you speed it up to 2x or so.

[chrisduerr]

perhaps the issue truly is in the Alacritty application itself.

I don't see any way in which that would be possible.

[jayache80]

I don't see any way in which that would be possible.

I agree. Since this problem reportedly occurs in both X11 and Wayland, I am looking at the underlying dependencies x11-clipboard and smithay-clipboard, respectively. Both use std::thread and std::sync::mpsc (multiple producer single consumer). I have a hunch that those provide a mechanism that allows this "queuing" or "caching" behavior to occur.

[chrisduerr]

Both use std::thread and std::sync::mpsc (multiple producer single consumer). I have a hunch that those provide a mechanism that allows this "queuing" or "caching" behavior to occur.

These datatypes certainly don't have that inherent problem. As mpsc already clearly states in its name, there might be multiple producers, but the values are all consumed by a single consumer without any duplication.

[ryaminal]

This same behavior has started happening to me. Seems to be isolated to alacritty. If the problem is happening and I paste in to another terminal app(Gnome Terminal) then the pasting works without the "queuing". If I restart alacritty and try then it seems to work again.

Next time this happens, what's the most helpful thing I can gather to try and diagnose this? Logs, I suppose. Anything else?

alacritty version: 0.10.1

[simisimis]

I have been having this problem as well on sway with alacritty. I always thought it was a tmux thing. But now that I quick using tmux and this problem appeared again. I don't think it happens because of the process running long enough.
Sometimes it goes two levels deep. Meaning I copy something somewhere in or outside browser and I need to paste 2 different old values before I get to paste a correct(latest) one.

[AttilioGreco]

I am hitting samting similar.
Copying from alacritty to alacritty or from an instance (Browser Editor) to alacritty, and it keep the old clipboard values.
And it looks like there are multiple layers, if I paste 3 times I can get the value that I have in the clipboard.
This issue is happening just with alacritty, no problem observed with VScode telegram or Firefox.

alacritty --version
alacritty 0.10.1

Fedora release 37 (Thirty Seven)

Setup with tmux

[kylemanna]

I've been observing this as well for some months assuming it was my setup.

Details:

• Arch Linux
• alacritty0.12.2 (9d9982df)
• tmux 3.3a
• swaywm version 1.8.1
• clipman 1.6.2 invoked with wl-paste -t text --watch clipman store --no-persist

The symptoms are:

1. System works fine for some time (days, weeks).
2. Suddenly, something I paste into alacritty is the previous (not latest) clipboard value. Pasting twice fixes it. In extreme cases it's 3 levels deep.
3. Other windows (i.e. Chrome/Brave Browser) don't exhibit the issue.
4. Closing and restarting alacritty resolves the issue.

[acidkewpie]

Happened under Xorg / i3, happens now under Wayland / Hyprland. Common denominator - Alacritty. Cmon guys...

[kchibisov]

I'd suggest to retest alacritty on the recent master.