Probably a dupe of bug 120625.
Which application are you using as source ?
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build

I tried with LO Dev 6.2.1 and still doesn't work. 
I tried copying from Bluefish and Chrome. Only works within LO (from Calc to Writer, for example).
But, with the Dev version, it now copies from Writer to Bluefish (6.2.0.3 doesn't)

I'm also on Linux x86_64 and gave this a quick go. Yep I *can* confirm what Marcel is experiencing. Sort of. The issue appears weirdly inconsistent for me and it's likely Qt5 VCL plugin dependant.

I'm on Mageia 6 using KDE Frameworks 5.42.0 (Qt 5.9.4). I tried copying the text from this bug report into Writer from Firefox (60.5.0 ESR) as well as some gibberish I typed into KWrite (KDE's notepad app).

Day-to-day I still run LO with VCL set to the old GTK2 plugin. Also, I still normally run with OpenGL disabled. Under these conditions (VCLPLUGIN=gtk; OpenGL disabled) I cannot reproduce Marcel's issue. However, if I switch to Qt5 what he's reporting does manifest itself for me.

With VCLPLUGIN=qt5 active (OpenGL enabled or not doesn't seem to matter), Writer struggles to insert large blocks from the clipboard buffer. I say "struggles" because if I press CTRL+V just once nothing happens. If I press it again and again: nothing. But if I hammer CTRL+V a dozen or so times the buffer *will* eventually suddenly puke out onto the screen. Otherwise, if I instead right-click with my mouse and select "Paste" from the context menu, the buffer seems to insert on the first try, every try, without issue. Single words appear to paste fine either way using the keyboard shortcut or context menu.

@Xisco: From what I witnessed in my experimentation above, bug 120625 strikes me as a different animal.

@Marcel: Which Linux distro are you on and what desktop environment are you using? In LO, which VCL are you running? The answer to that last question is located under Help -> About LibreOffice. I'm betting you're set to Qt5.

Also try this: with LO shut down, open a terminal window and copy-paste the following command line:

libreoffice6.2 --writer -env:SAL_USE_VCLPLUGIN=

Your options after the '=' are:
    'gen'  (Generic X Windows);

    'gtk'  (GTK2 -- this one causes *me* the fewest headaches over all);

    'gtk3' (GTK3 obviously);

    'kde4' (with OpenGL active gives me screen corruption -- use at your own risk!);

    'kde5' (this one is new for 6.2.x -- I understand it to be a GTK3/Qt5 hybrid[?]);

    'qt5'  (also new with 6.2.x -- *should* be ideal for KDE Plasma 5 users);

Try them with and without OpenGL active (Tools -> Options -> LibreOffice : View) and report back your findings. Unless you're actually using KDE you can probably skip 'kde4' and 'kde5'. I could only reproduce your bug with the Qt5 plugin.

Hope this helps. Note that I'm not a developer; only a fellow user with his own issues (see bug 123285 and please confirm if you've got it too).

John: I'm using OpenSuse Leap 15 and VCL kde5.

(In reply to Marcel Leal from comment #4)
> John: I'm using OpenSuse Leap 15 and VCL kde5.
@Marcel: And presumably KDE Plasma 5 is your desktop then? Did you try the command line I suggested above with other VCL options? Do 'gtk' and/or 'gtk3' still exhibit your issue or do they work around it?

--

@The Devs: Given Marcel's VCL setting, I ran another experiment on my system focusing exclusively on the 'kde5' plugin (Nouveau video drivers; OpenGL off; Hardware Accel on). Again copying the text of this bug report out of Firefox.

It worked fine! ...and then it didn't. This must have fooled me yesterday (in comment 3).

Sometimes it works, and when it works it keeps working, but when it doesn't, it doesn't work at all.  I went to Firefox, selected a large block of text with CTRL+C. Switched to Writer, CTRL+V. It worked! It worked repeatedly. Then (still in Writer) tried SHIFT+ALT+CTRL+V (Paste Special / Unformatted). That failed! Repeatedly. Tried only CTRL+V again. Now it failed too. Repeatedly.

Back to Firefox, CTRL+C on the selected text again. Back to Writer, CTRL+V. Failed! Back to Firefox. Back to Writer. CTRL+V worked again! SHIFT+ALT+CTRL+V failed. Now CTRL+V failed again as well.


NEW OBSERVATION 1

Strangely, unlike my findings yesterday (with the 'qt5' plugin), mouse selecting either Paste or Paste Special -> Unformatted from the right-click context menu *fails* (using the 'kde5' plugin) the same way the keyboard shortcuts do.

So to be clear: With 'qt5' the mouse-method keeps working while the keyboard fails sporadically. With 'kde5', the keyboard fails sporadically, but the mouse-method *never* seems to work. Also with 'kde5', Paste Special / Unformatted *never* works at all using either keyboard or mouse.


NEW OBSERVATION 2

With Formatting Marks set to visible, every failed paste attempt still inserts at least one paragraph break. Usually one, but sometimes two.


NEW OBSERVATION 3

The experimentation above was all done with large chunks of text. Copy-pasting a single word, *does* seem to work consistently (just as it did with 'qt5'). If I copy some text from within a paragraph, that also appears to work okay. But all bets are off copying multi-paragraph blocks of text!


POSSIBLE (?) CONCLUSION

Text in the clipboard buffer containing line breaks will likely fail to paste into Writer if the active VCL plugin is 'kde5' or 'qt5'.


OTHER WEIRDNESS

Before I finished with this round of experiments, I discovered some of my custom keyboard shortcuts were failing (bug 123287 perhaps?). Those that set paragraph styles no longer worked. Those that dictated character styles still did.

Then, after closing my text document, I tried bringing up the Template Manager with CTRL+SHIFT+N (as I often do) and to my surprise the "Ambiguous Shortcut Detected" error dialog popped up:

   The key sequence 'Ctrl+Shift+N' is ambiguous. Use 'Configure Shortcuts'
   from the 'Settings' menu to solve the ambiguity.
   No action will be triggered.

What the... ???  CTRL+N to bring up my default template (which is not the "Default" default template) still worked fine.

After closing this (kde5) test instance of Writer, I started a new instance with my usual 'gtk' settings and *everything* was back to (reliably functioning) normal.

Up until now I was under the impression the VCL plugins just interfaced with the graphics/widget API of the underlying desktop environment to generate eye candy. Clearly they  do a lot more than that!

I can confirm this.

Paste doesn't work after a copy from Firefox.
The text presents correctly in Clipboard.
Additional fact - the paste works immediately after opening the document in Writer, and later (not sure if time or anything else related) doesn't work.

Version: 6.2.1.1
Build ID: 1:6.2.1~rc1-0ubuntu0.18.04.1~lo1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: kde5; 
Locale: he-IL (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Kubuntu 18.04.2 64bit
KDE 5.12.7

This sounds very much like bug 122689 (and a little bit like bug 123115), whose fix just made it to master yesterday. Could you please do a retest with a daily build of master that contains this fix (i.e. today's daily build or newer) and check whether the issue still occurs?

I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build

Looks like fixed in 6.2.2
Yay!

Version: 6.2.2.2
Build ID: 1:6.2.2-0ubuntu0.18.04.1~lo1
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: kde5; 
Locale: he-IL (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Kubuntu 18.04.2 64bit
KDE 5.12.7

Thanks for retesting with the latest version.
Setting to RESOLVED WORKSFORME as the commit fixing this issue hasn't been identified.