(In reply to comment #1)
> Any chance you can try reproducing this on a different version of Windows?
> (e.g. Win7, XP etc)
> 
> How big is the text you are pasting? 5 lines? 50 lines? 500 lines?
> 
> Are you pasting into an empty document? Or an existing document?

I frequently cut online newspaper articles from Firefox and paste into LibreOffice Writer.  Using the release 3.6 and the RC 4.1 after several cut and pastes LibreOffice gets stuck and will only paste an old paste.
At that point I can cleanly paste into Microsoft Word but not LibreOffice without exiting the program and reloading LibreOffice.
I am using Windows 8 Professional with up-to-date patches.  I can repeat this easily and it stops me using LibreOffice as this becomes tiresome.

I do not have older versions of Windows available.  Can easily replicate after 4 or 5 paste operations.  Can supply screen recording if needed.

I can confirm this problem is still a repeatable bug in LibreOffice 4 rc 2 using Windows 8 Pro.

(In reply to comment #4)
> I can not confirm this for LO 4.0 RC 2 Win 7 64bit. I have no Java installed.
> 
> Maybe Java is the culprit? Try uninstall Java and report back if it helps.

I can confirm problem still exists in Writer without Java with version 4.003 and Windows 8 Professional. Problem appears randomly - pasting in Word 2010 at point of problem is OK so problem is Writer specific. I could run debug version if you have one.  I have had periods where 20 pastes are OK before the problem - other times after 2-3 pastes. Each time I'm pasting newspaper articles and copying a  heading to create a filename. Writer retains the heading and not the next paste.
Restarting LibreOffice clears the problem.

It looks like you guys have found the same bug as I have found?
For me File Explorer on Win8 needs to be closed to make copy/paste work without issues. Release version or latest Dev it is all the same.
It is possible that other applications too can create this effect on LibreOffice. For me this has been possible to replicate on a fresh install of Win8 with only Panda Cloud Antivirus and Windows debugger installed. Nothing else is currently running on the system.
Works fine without an open File Explorer. Open File Explorer, open an odt (I guess any filetype works) or create a new one (leave File Explorer open), copy and paste some text (one or a few times), and it does not work properly anymore.

This does not affect either WinXP or Win7. Only Win8, and only with File Explorer open (in my case).

If you have not seen my bug newly added as an "see also" here it is:
https://bugs.freedesktop.org/show_bug.cgi?id=64235

(In reply to comment #9)
> I can confirm this is still a problem on Windows 8 using Version 4.0.3.3.

Same for me. I have ran the debug version and collected info the best I could on this. But it was too close to the 4.0.3.3 release I guess. Hopefully my info have helped someone developer at least. If only my programming skill were less limited...

Can you always replicate this regardless of what applications you have open otherwise?

https://www.youtube.com/watch?v=hQm_JVdOpx4 , first attempt crash

*** Bug 68013 has been marked as a duplicate of this bug. ***

I confirm this paste bug is still a problem with Version 4.4.1.2. 
Here is either the same or very similar paste bug I've reported in Writer. 
https://bugs.documentfoundation.org/show_bug.cgi?id=90120

I'm using Win7 64, and Win XP 32.

*** Bug 68013 has been marked as a duplicate of this bug. ***

Error was solved in last versions of 4.X but now appears again in 5.0.5.2 in a similiar way.
I paste a text from Thunderbird into LO Write - works fine.
I try to copy a second text:
The "Clipboard"-Icon in LO changes from coloured to gray and no paste is available.
I push Ctrl+C a second (or sometimes a third or fourth) time - Clipboard-Icon becomes coloured again and paste is available.

In 5.2.7.2. Bug is still present. As it occurs just once a day it is hard to reconstruct. Still after copying Text from Thunderbird (52.6.0 - 32 bit) the Clipboard-Symbol disappears. Repeating Ctrl+C once or several times lets the symbol appear again an text can be pasted.
May be important, that the text is combined with database for Mailings.

(In reply to Kevin Suo from comment #26)
> I have been suffering from this bug for a long time, in Linux, but I never
> had a chance to get the steps to 99% reproducing this.
> Most of the time I was trying to copy paste from PDF documents and
> frenqently switching between windows when this bug incurre.

Adjusting fields as this is not Win-only after all

Seems like I have found a way to make it reproduceable:

1. Open Vivaldi or Opera (possibly any chromium based browser might work...)
2. Go to https://www.heise.de/newsticker/
3. mark and copy (CTRL + C) the first newsticker headline (but ONLY the headline, currently for example "Malware-Angriff legt US-Wettersender zeitweise lahm". Do NOT rightclick the link and copy the link, but mark the text and copy the text. This is why Firefox or IE doesn't work, because you can't select the text there.
4. open a new Writer Document
5. paste the clipboard with CTRL + SHIFT + V -> unformated Text -> OK
6. Make a new line in Writer
7. Copy the second newsticker headline
8. try to paste clipboard in writer with CTRL + SHIFT + V -> unformated Text -> OK
9. If its still working on the second try, try again. It shouldn't take long to make it break.

Result for me:
the first paste is working, the second doesn't. If that happend once, there are some interesting effects:

1.) You cant paste with CTRL + SHIFT + V but you can still paste with CTRL + V
2.) Even though CTRL + V does work, the options in the GUI (EDIT -> PASTE) does NOT work
3.) restarting LibO (including quickstart) brings everything back to normal, but its reproducable

(In reply to bugzilla2 from comment #28)
> Seems like I have found a way to make it reproduceable:
Thank you very much. I used those steps for Bug 116983 that's similar, maybe the same, but somewhat different result on first paste.

*** Bug 127428 has been marked as a duplicate of this bug. ***

Problem is WORSE in Version 6.2 til 6.3.4.2 (x64)

Not enough that its difficult to copy unformated Text Thunderbird -> LibO.
Some times (twice a month I'd say) when trying to copy from LibO -> Thunderbird, LibreWriter hangs without any respond.
To kill the LibO-Session will solve the problem just for a little time - after some attempts it'll hang again. Only restarting the whole Windows 10 will give you the chance to work further for one ore two weeks. So it seems to me, that there is something wrong with Caching the data.

*** Bug 131745 has been marked as a duplicate of this bug. ***

this: 

some copy - pastes work, at one point it stops working, after that happened: 

> 1.) You cant paste with CTRL + SHIFT + V but you can still paste with CTRL + V

from c#28 happened to me when copying headlines from 'bugs' into calc 6.2.8.2 in the way described in c#28, thus not writer specific but an overall LO problem.

I also suffer (really) from this issue. For ages. Today I found out that if you insert a comment then the clipboard options become enabled and you can paste into the comment.

So the situation is as follows:
- I copy from another app.
- cannot paste from the menu
- shift-ctrl-v does nothing

Then when I insert a comment en set the cursor in the yellow widget and press shift-ctrl-v the paste dialog pops up and I can paste.

So Libreoffice seems aware of the new clipboard content but did not update it's UI correctly.

Xisco, Buovjaga, please suggest someone to invite to see this. 
Very annoying in daily word-processing and one of many paste bugs.
I retested steps from Comment 28 in Win LO 7.0+ with Chrome and they are valid.

While I can easily reproduce "no paste is available in toolbar and right-click menu, while Ctrl+V is working" in LO 6.3 as I wrote in bug 116983 but not in master 7.1+ so hopefully improved (albeit may not be fully resolved).

Seems I was happy too early :/

Bug still reproducible in:

Version: 7.1.0.0.alpha0+ (x86)
Build ID: 3ba009e0c2b7800305103f8ec86df58625fed955
CPU threads: 12; OS: Windows 10.0 Build 17763; UI render: Skia/Vulkan; VCL: win
Locale: de-AT (de_AT); UI: en-US
Calc: CL

i do see some progress, 

a test done some days ago - 1. copy part of bugzilla headline, 2. paste in calc, 3. paste in writer, 4. copy part of next bugzilla headline, 5. repeat from 2. - which failed after 7 cycles did 16 cycles today without fail (test stopped, not by fail) with ver: 

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL

besides not! being statistical significant it spreads some hope, as well as seeing competent people addressing the problem, 

this info: https://bugs.documentfoundation.org/show_bug.cgi?id=57147#c36 might be very important, if 'copy/paste' is somehow linked to 'comments' (and their entanglement with the drawing layer?), which as a special minefield has been undermining calc for years and is still doing so, then this could be an indication of the source of the evil, and it would be an explanation why no programmer has yet come close to the problem, 'comments' are so intricately interwoven in the code that several programmers have given up on 'i did what i could', 'monster', 'should be reworked in general' and so on ... 

a question in passing, i recently saw in 'calc core change' a presentation of Kohei with the 'old' data model compared to the 'new' one with 'shared formulas', 

somehow I was missing the 'comments' in the new model, were they only forgotten in the graphics, or are they missing in the data model and were constructed afterwards or 'externally'?

(In reply to Telesto from comment #43)
> Based on comment 28 or 'only' seeing in happen again. And thanks for testing
> LibO 7.1 :-).

Yes, reproduced with the steps from comment 28. Failed as always on second paste. First paste works, second fails.

@bugzilla2: 

could you please retest, i followed the steps from c#28, exactly, win7x64 SP1, new installed Opera 69.0, LiBo ver. see below: 

could copy 4 headlines as unformatted text without any problem, stopped the test (not by fail), copy content e.g. 'Best of Informationsfreiheit: Kernbereich exekutiver Eigenverantwortung', 

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL

can't say which of our LiBo ver. is older - as the ver.-description lacks a date and build-ID's aren't sequential, :-(  (enhancement request) - but they are different ... mine was downloaded 2020-06-25 ~16:30 h MEST, if you can tell me your download time or provide a link i'll try to get it and do a cross test ...

(In reply to b. from comment #45)
> can't say which of our LiBo ver. is older - as the ver.-description lacks a
> date and build-ID's aren't sequential, :-(  (enhancement request) - but they
> are different ... mine was downloaded 2020-06-25 ~16:30 h MEST, if you can
> tell me your download time or provide a link i'll try to get it and do a
> cross test ...

The build was as new as yours: https://git.libreoffice.org/core/+/3ba009e0c2b7800305103f8ec86df58625fed955%5E!/

(In reply to bugzilla2 from comment #44)
> (In reply to Telesto from comment #43)
> > Based on comment 28 or 'only' seeing in happen again. And thanks for testing
> > LibO 7.1 :-).

The steps to reproduce don't work for me
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 006c65bbd472cb1d7d44e095714e28190b76be0d
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: de-DE (nl_NL); UI: en-US
Calc: CL

BTW, not denying they issue; the problem is truly present. I still have some ways to illustrate, however the belong to the more 'exotic' ways to reproduce. So there are some validity concerns/ refraining to confirm (which don't hold IMHO) 

BTW, we are talking about 'stock' Windows without other applications, especially clipboard managers etc active (again, not that it should matter at all.. )

Hmmm, strange....
Good Thing is: Copy Paste is working for me now :)
Bad Thing is: It seems my steps (comment 28) are useless now :/

I have retested today with a current x64 master build and I couldn't reproduce the problem. So I thought, maybe its a 32Bit 64Bit thing and retested in x86 Master - still not reproducible. So I retested in 6.3.6 -> again working perfectly. Then I thought that maybe the x64 Visual C++ Runtime (necessary for x64 Libo) could have some impact. So I uninstalled that again and rebootet. Still working... I also did a freh install with Windows 10 1809 and LibO 7.0 Beta 2 32Bit in VirtualBox -> not reproducible and tried Webarchive-Version of the Newsticker -> not reproducible.

Copy Paste was definitely NOT working Friday Afternoon (when I wrote my Newsletter) and also NOT on Saturday during my tests with 7.0 Beta 2. And Today its working in ANY version - strange.

Since there were no other Updates to my system in the last two days, my guess is, that Heise has changed something on the website, so that it doesn't trigger the bug anymore... Good for my work, bad for testing...

Seems like we need new steps for testing...

(In reply to bugzilla2 from comment #48)
> Hmmm, strange....

... 

> Since there were no other Updates to my system in the last two days, my
> guess is, that Heise has changed something on the website, so that it
> doesn't trigger the bug anymore... Good for my work, bad for testing...
> 
> Seems like we need new steps for testing...

as i believe in your detailed description i agree that a change at heise is likely ... but may be something else as well, 

some of these bugs have annoyingly many helpers to hide from being catched,  

bad news from my side, tried with PasteSpecialBug.pdf from tdf#65606, had 20+ good tries yesterday morning, did a cross-check with 6.1.6.3 in the evening, repro after 7 tries, checked with 7.1.0.0.a0+ again, repro after 7 tries ... :-( 

it looks as if the formatting in (un)bold from that pdf has some 'specials' when copying ... i had: 
- rows copied in bold but the 'B' in the toolbar not 'active', 
- even with copying as 'unformatted text', 
- formattings 'exceeding' the row and affecting the next one, 
- the fails happened short time after i deleted that formatting by clicking 'bold-B' with newline-sign marked, 

i had ctrl-v and! shift-ctrl-v failing and! shift-ctrl-alt-v (mentioned somewhere) needed three attempts to start working, after that ctrl-v and shift-ctrl-v came back to live too, 

closed all LO programs, started calc 7.1, made a new textdocument with 7.1, repeated test, 21 consecutive pastes without fail, stopped test (not by fail), 

started calc 6.1.6.3 besides 7.1 still running, opened new 6.1 textdocument, 9 consecutive copy-pastes (ctrl-c ctrl-v row 1, 3, 5 - repeat) from Acrobat Reader to writer, no fail, after that tried paste special, second crtl-shift-v failed, nothing happened, after writing this paragraph in notepad tried ctrl-v in writer, worked, ctrl-shift-v still not working, ctrl-shift-v into notepad works, 

switched to 7.1, the document still open from the 21 correct pastes, neither ctrl-v nor ctrl-shift-v nor! ctrl-shift-alt-v working, each more than 10 tries, notpad ctrl-v and ctrl-shift-v working proves clipboard ok, 

tried heise newsticker -> writer 7.1 again, first headline ctrl-shift-v ok, second and third with ctrl-v ok, fourth with ctrl-v not! ok, no reaction, neither with paste special, paste in notepad ok, see here: 'C++20: Optimierte Vergleiche mit dem Spaceship Operator', 

assume: something is still wrong, it might be that the test with the old ver. (or the old ver. open in parallel) is affecting 7.1, it might be that 7.1 is 'clean' or 'cleaner than prior versions ... 

frustrated ... some one-armed bandits are easier to understand, 

is there anything that LO affects / interacts with any system settings (registry?) or windows system files? .dll's? that it might be that the test with 6.1.6.3 had bad influence on the following with 7.1 

i'd like if other testers cross-check: 
LibO 7.1 alone good working for some (long) time, (heise and pdf), 
LibO 6.1 or other old ver. opened parallel failing quite soon, 
after that LibO 7.1 failing too, 

(i know that @bugzilla2's results nearly deny this, but he hadn't the different ver. open in parallel?) 

will try to reproduce in linux and if possible to get backtrace later ...

(In reply to b. from comment #49)
> i'd like if other testers cross-check: 
> LibO 7.1 alone good working for some (long) time, (heise and pdf), 
> LibO 6.1 or other old ver. opened parallel failing quite soon, 
> after that LibO 7.1 failing too,

6.1, 7.0 mix -> failed on 7th try (2x 6.1 Docs + 6.1 Quickstart + 7.0 Quickstart)
6.1 only -> given up after 16th Try
7.1, 6.1 Mix -> failed on 5th Try (2x 7.1 Docs + 7.1 QS + 6.1 QS)

So yes, having two different versions with Quickstarter running makes it more reproducible :)

But something must have changed, because it was a lot easier and faster to reproduce this a couple of days ago.

Also, some might say, that having two different Quickstarter-Versions running in parallel is not a common scenario, and they are right ;) BUT, this bug definitely is also triggered with only ONE version running at a time, so this workaround only makes it easier to reproduce...

Bug still present in 6.4.5.2 (x86). Just happend in regular work case, no test.

Created attachment 165387 [details]
varying results from pasting ...

retested with 7.1.0.0.a0+, 

bug still there, recipe from c#28 works, 

special: 

'1.) You cant paste with CTRL + SHIFT + V but you can still paste with CTRL + V'

from c#28 isn't like that everytime, just had ctrl-v blocked too, 

add. observations: 

while another calc is busy copying commented cells, macro with 
'Dispatcher.executeDispatch(document, ".uno:Paste", "", 0, Dummy())' 
windows clipboard is blocked, 

pasting to calc and writer varies, calc: time and headline concatenated in one cell, while writer has a paragraph mark inbetween, 

second paste in writer (after a repeated ctrl-c in opera) - mostly - results in different color, 

different display in calc 6.1 / 7.1, hyperlink included in both and both functional, 

nasty bug ...

Created attachment 166145 [details]
screenshot_with_'splitted_focus'

found another variant of this (or another variant of copy-paste) bug: 

0. working in a big sheet, replacing formulas (patching strings together) by their resulting string, 
1. find a cell with a strng formula, ctrl-f and search for '&', 
2. escape from search box by ESC, 
3. run macro - see below - by assigned keyboard shortcut (alt-F7 n my case), it copies the actual selection and pastes it back as it's result with 'paste special', 
4. ctrl-f and search for the next occurence of '&', 
5. escape from the search box by ESC, 
6. in this situation the sheet is displayed as in the attached screenshot, the 'old selection' / replaced cell is 'highlighted' with light blue-grey background, a dotted border and the small black 'expand-square' bottom-right, and the new / found cell is marked with the thick black border, 
7. starting the replace macro in that situation results in a short display of the hourglass and 'no action', the formula stays as formula, 
8. changing the 'focus' / 'selection' by e.g. cursor-up - cursor-down (which results in the new found cell being selcted and the highlighting of the former cell disappearing) enables to start the macro with expected result, 

it could be that some variants of the 'focus' / 'selection' status, being 'splitted'? (a thing that i had never consciously seen before) somehow plays into copy/paste ... ??? 

(only reported because this bug has been unsolved for such long time and it might be helpful to point out exotic side effects, and it looks to me as a 'stable reproducer'), 

experienced in ver 6.1.6.3, retested in 7.1.0.0.a0+, same effect, 

the macro (recorded and cutted away an unneeded cell change in the beginning): 

++++++++++++
sub replace_formula

rem ----------------------------------------------------------------------
rem define variables
dim document   as object
dim dispatcher as object
rem ----------------------------------------------------------------------
rem get access to the document
document   = ThisComponent.CurrentController.Frame
dispatcher = createUnoService("com.sun.star.frame.DispatchHelper")

rem ----------------------------------------------------------------------
dispatcher.executeDispatch(document, ".uno:Copy", "", 0, Array())

rem ----------------------------------------------------------------------
dim args4(5) as new com.sun.star.beans.PropertyValue
args4(0).Name = "Flags"
args4(0).Value = "SVD"
args4(1).Name = "FormulaCommand"
args4(1).Value = 0
args4(2).Name = "SkipEmptyCells"
args4(2).Value = false
args4(3).Name = "Transpose"
args4(3).Value = false
args4(4).Name = "AsLink"
args4(4).Value = false
args4(5).Name = "MoveMode"
args4(5).Value = 4

dispatcher.executeDispatch(document, ".uno:InsertContents", "", 0, args4())

end sub 'sub replace_formula
++++++++++++

*** Bug 128298 has been marked as a duplicate of this bug. ***

*** Bug 136631 has been marked as a duplicate of this bug. ***

*** Bug 136567 has been marked as a duplicate of this bug. ***

Marked "All OS"; Windows part might be fixed by tdf#136175.

Seems to be fixed in tdf#136175 :)

Can't reproduce it in current master build, whereas its easily reproducible in any previous version.

Just hope it got backported to 7.0 and 7.1 ...

Would be great if more users affected by this problem could test latest nightly build and see if this problem is fixed:
https://dev-builds.libreoffice.org/daily/master/current.html

Leaving this open until more testing was done.

Hi, as I also faced the copy-pasted bug so I have tested the proposed nightly build for a hour and for me it seems to work.

For further purposes I also add my description of the problem I had faced, as I did not see this behavior mentioned in other bugs:

Copying text from any 3rd party source (web-Firefox, pdf-Foxit Reader, MS Word...) etc worked only sometimes (alike as in other bug reports), mostly first time. 

But I had noticed that LO recognized the text which was clipboarded in 3rd party indeed, as the clipboarded text you could paste for example in the FONT NAME rectangle or to SET PARAGRAPH STYLE rectangle (placed between icons) although PASTE did not work directly to Document/Writer. 
This happened after I had upgraded from 6.4 to 7.0/7.1. So in the case the paste/paste without formatting did not work, I used to paste the clipboarded text firstly into FONT NAME rectangle (which worked) and the copied it (CTRL+A, CTRL+C) one more time to the clipboard and after this the PASTE into the Writer/Document text worked. So there was some problem with pasting the text only directly to Writer/Document. Maybe this helps a bit.

Thanks for testing @Orwel.

Setting to Fixed Verified, as https://bugs.documentfoundation.org//show_bug.cgi?id=136175 seems to have the fixing commit.

I would encourage any remaining issues to be filed in a new bug as that would then be related or different problems which should go through a new triage process to be properly tackled.

This is Windows only bug. All users and duplicates are Win, except one comment. 
Linux is bug 99818. Not sure if there's bug there ,none of 10 users responded for a long time.