Have just run into this or a similar problem again after just running an emacs macro against a large file. The macro cut some text, which ends up putting it on the system clipboard. I don't think that it grew the system clipboard to a huge size, but rather repeatedly replaced the contents of the system clipboard. After running this macro, both the container and the *entire browser* are wedged. The cache is busy, which indicates to me that the system clipboard is implemented via browser cache operations, and they're not reliable.

To reproduce:

1) Open the attached file in emacs inside Crostini
2) Start a keyboard macro:

      Ctrl-x (

3) Search for the end of the text "pool":

      Ctrl-s pool":

4) Stop searching and move to the open bracket:

      Ctrl-f

5) Start selecting:

      Ctrl-space

6) Search for close bracket:

      Ctrl-s ]

8) Copy this text:

      Alt-w  (or: Esc-w if key bindings aren't 100% set up for this)

9) Move to beginning of line:

      Ctrl-a

10) Paste:

      Ctrl-y

11) Cut to end of line:

      Ctrl-k

12) Move to beginning of next line:

      Ctrl-a Ctrl-n

13) Stop recording the macro:

      Ctrl-x )

Now you can invoke this macro via:

      Ctrl-x e

and repeatedly invoke it by pressing "e" many times.

You'll be able to process the whole file, but the terminal, the Crostini environment and the whole browser will be irrevocably wedged afterward.

Raising to P1. This bug makes the container environment nearly unusable for development.

dcastagna@: any chance you could help route this to the appropriate people? Thanks in advance.

Deleted: mac-minis-caches-orig.txt 200 KB

mac-minis-caches-orig.txt 200 KB View Download

This looks like a Chrome browser bug related to the clipboard subsystem. I have no clue how that works. Punting back to dcastagna@

How does Crostini's system clipboard work? Is it layered on top of the browser's copy/paste functionality? Adding Blink>DataTransfer if so.

It is, it uses the wl_data_offer interface to integrate with Exo.
Just looking at the data offer code in exo, it seems like Niwa had done some work around there. Assigning to him, please redirect as appropriate. 

kbr: are you pasting into Terminal ?  or into a Linux app ?  if it's Terminal, that's just HTML/JS code, so that isn't using any of the wayland/exo/etc... code paths.

See c#1; this is happening when running windowed-mode emacs under Crostini. When emacs cuts text, it goes on the system clipboard.

I've also managed to provoke this per the original bug report by pasting large amounts of text into the Terminal which was running "cat > foo.txt". But the fact that the system clipboard in Crostini is unreliable and can wedge not only the container environment but the whole browser is a showstopper.

Marking this R-B-S for M72 so this gets attention, and triaged. This is a serious reliability issue that breaks the container environment when it happens, requiring a reboot to fix.

niwa@ hasn't visited this issue tracker in over 30 days. Who can own this bug?

wayland copy-paste was implemented by hirono I believe.

Note that the problem may be around wl_data_source, which handles data transfer in the crostini -> chrome direction. wl_data_offer is for the other direction.

I guess we need someone from the crostini team to work on the issue. I was asked by the crostini team to create the initial implementation of clipboard because there is some overlap between ARC++ and crostini. After that there is no explicit owner but reveman@ was taking care of the clipboard as a part of exo. Now he moved from the team.

tbuckley@ - could you find new owner for the issue?