Able to reproduce the issue on reported chrome version 69.0.3497.81 also on latest chrome 71.0.3550.0 using Ubuntu 14.04.  

Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.

NOTE:Issue not seen on Mac and windows.

Thanks..! 

Does the same thing apply to pasting into a contentEditable div or a textarea?

Neither gmail nor sheets use the built-in text editing; they all parse the pasted data and significant processing in script before it appears on the page. i.e. this could be a product bug.

Just tried it on the textarea from
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_textarea and yes,
I get the same symptoms.

On Chrome OS M68 I'm only seeing a paste of the contents of http://www.gutenberg.org/cache/epub/33129/pg33129.txt into gmail or sheets take a few seconds. Paste into this field here took less than a second.

I'll give it a try on Ubuntu.

Mmm, that is also fast for me. Maybe it's because it's a Chrome-to-Chrome
paste? My issue is when I'm pasting from the clipboard (see repro
instructions).

Okay, repro for me on linux (M69). Confirmed in gmail and textarea. The whole renderer process freezes (not just one tab), but not the browser or other cross-origin tabs. 

Interestingly, if you replace the clipboard contents while the tab is frozen, the new contents are what end up showing up!

Also noted:

* Copy/paste within Chrome is not affected.
* It also doesn't affect this:

(for n in {1..1050}; do echo $n; done) | xclip -i -selection clipboard

So... what is the difference between xsel and xclip in this case? Any Linux gurus?

Interesting...

$ echo "hello" | xclip -in -selection clipboard
$ xclip -selection clipboard -target TEXT -out
hello
$ xclip -selection clipboard -target TARGETS -out
TARGETS
UTF8_STRING

$ echo "hello" | xsel --clipboard 
$ xclip -selection clipboard -target TEXT -out
hello
$ xclip -selection clipboard -target TARGETS -out
TIMESTAMP
MULTIPLE
TARGETS
DELETE
INCR
TEXT
UTF8_STRING
STRING
X Error of failed request:  BadAtom (invalid Atom parameter)
  Major opcode of failed request:  17 (X_GetAtomName)
  Atom id in failed request:  0x0
  Serial number of failed request:  24
  Current serial number in output stream:  24

Theory: xsel puts a bad type on the clipboard; this causes xsel to report an error. When Chrome is enumerating the types it gets stuck on the bad type. If you replace the clipboard contents then Chrome gets unstuck.

But the size of the clipboard contents also matter, somehow. "hello" pastes fine in the above examples. Less than 1020 lines pastes fine. Somewhere above that it hangs. Weird.

Tweaking the bug title.

Debugging notes: 

Pause is inside AuraX11Details::RequestAndWaitForTypes. 

The length of the delay comes from a 10s timeout on converting types, and trying multiple types. SelectionRequestor::PerformBlockingConvertSelection waits on the run loop until the abort fires.

It looks like OnPropertyEvent, OnSelectionNotify, and OnPropertyEvent (again) are called, but early-exit without calling CompleteRequest, hence the timeout.

Specifically, in SelectionRequestor::OnSelectionNotify, request->target != event.xselection.target triggering the early exit.

If a smaller number of lines is pasted, this case is not hit.

(and I'll stop investigating now)

Repro'ed on Linux and Chrome 69. As previously mentioned:
- pasting fails only with xsel-to-chrome (not chrome-to-chrome or xclip-to-chrome)
- pasting only fails with sufficiently large text

Pasting this sufficiently large xsel-copied text into the omnibox can hang all omniboxes and all text entry boxes on all tabs in the same window. Chrome does recover after ~30 seconds, but this seems concerning.

I also noticed that while the renderer is hung on xsel paste, you can un-hang it by copying another, valid (not >1000 line && xsel) text, at which point the renderer will resume and have pasted the later-copied valid items. This is probably a result of the retries mentioned in #10

From https://keithp.com/~keithp/talks/selection.ps , section 8, Selection Timeout (paraphrased):
The default value which Xt uses to wait for the source of copy data is 5 seconds [..] A common reason for having the selection take so long is that the owner is sitting inside the ConvertSelection callback computing the value before returning it for transmission. When the selection is large, and the data must be reformatted, this can take quite a long time. To avoid this problem, the application must perform the incremental operation itself, using XtOwnSelectionIncremental, so that it can send the first chunk of data as soon as possible.

Therefore, I hypothesize that xsel fails to implement streaming the data (xclipboard and other services likely do stream successfully), or otherwise takes a long time to send a message. Therefore, Chrome assumes that xsel failed, and retries before timing out again, ad infinitum.

While I haven't checked if this is right, if it were I'd suggest only retrying for a fixed amount of times, say 3, or just not so much that the user thinks the renderer has hung forever, and won't quit Chrome out of frustration.

I don't know much about how the X selection/clipboard mechanism works, but
one thing that confuses me is that in the repros being discussed xsel exits
immediately; by the time I try to paste into Chrome xsel is no longer
running. How can Chrome be talking to xsel?

@17, xsel puts data onto the x11 clipboard, which Chrome later requests information from.

@17 For reference, the x11 clipboard (or other native OS clipboard) is how different applications talk to one another within an OS.