Bug 57147 - EDITING: Paste stops working after several copy-paste (steps: comment 28)
Summary: EDITING: Paste stops working after several copy-paste (steps: comment 28)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.2 rc
Hardware: All All
: highest normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
: 68013 127428 (view as bug list)
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2012-11-15 09:05 UTC by Matti Ruhanen
Modified: 2020-06-29 10:11 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matti Ruhanen 2012-11-15 09:05:27 UTC
Problem description: 

Steps to reproduce:
1. Coping text into clipboard and paste it into writer. This working fine for a while (several copy/paste phases should happend).
2. Libre writer application stacking after many copy/paste phases (application not responding) and it taking ~4-5min while application working again proberly but paste not working anymore.
3. I should restart Libre Writer. Copy/paste working again. This same problem reproduced for me during same date several times. 

Current behavior:
Paste the text not working into Libre writer
Anywhere else the same working at the same time

Expected behavior:
Paste should work also for writer

Platform (if different from the browser): 
Win8 professional
Comment 1 billhook 2012-11-16 01:29:19 UTC Comment hidden (obsolete)
Comment 2 Mike Lister 2013-01-13 19:48:42 UTC
(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.
Comment 3 Mike Lister 2013-01-31 11:15:55 UTC
I can confirm this problem is still a repeatable bug in LibreOffice 4 rc 2 using Windows 8 Pro.
Comment 4 VX 2013-01-31 14:50:08 UTC Comment hidden (obsolete)
Comment 5 Mike Lister 2013-02-26 14:08:22 UTC
(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.
Comment 6 Mike Lister 2013-03-12 18:42:47 UTC Comment hidden (obsolete)
Comment 7 Mike Lister 2013-03-22 17:38:38 UTC Comment hidden (obsolete)
Comment 8 Mikael Jonasson 2013-05-05 21:24:50 UTC
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
Comment 9 Mike Lister 2013-05-13 17:40:35 UTC Comment hidden (obsolete)
Comment 10 Mikael Jonasson 2013-05-15 17:51:05 UTC
(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?
Comment 11 Mike Lister 2013-05-17 13:02:56 UTC Comment hidden (obsolete)
Comment 12 Mike Lister 2013-06-13 10:52:51 UTC Comment hidden (obsolete)
Comment 13 Mikael Jonasson 2013-06-15 08:30:26 UTC
https://www.youtube.com/watch?v=hQm_JVdOpx4 , first attempt crash
Comment 14 Mike Lister 2013-06-22 16:36:23 UTC Comment hidden (obsolete)
Comment 15 Jürgen 2013-11-04 08:15:46 UTC
*** Bug 68013 has been marked as a duplicate of this bug. ***
Comment 16 Sal 2015-03-22 03:29:12 UTC
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
Comment 17 Sal 2015-03-22 03:31:23 UTC
I'm using Win7 64, and Win XP 32.
Comment 18 Jean-Baptiste Faure 2015-03-28 13:33:20 UTC
*** Bug 68013 has been marked as a duplicate of this bug. ***
Comment 19 tommy27 2016-04-16 07:23:51 UTC Comment hidden (obsolete)
Comment 20 Jürgen 2016-04-18 09:11:13 UTC
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.
Comment 21 QA Administrators 2017-05-22 13:24:15 UTC Comment hidden (obsolete)
Comment 22 Jürgen 2017-05-22 13:34:55 UTC Comment hidden (obsolete)
Comment 23 Timur 2017-07-18 18:15:18 UTC Comment hidden (obsolete)
Comment 24 Jürgen 2018-02-26 12:36:39 UTC
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.
Comment 25 Timur 2018-02-27 10:41:58 UTC Comment hidden (obsolete)
Comment 26 Kevin Suo 2018-03-01 13:37:22 UTC Comment hidden (obsolete)
Comment 27 Buovjaga 2018-10-18 13:19:14 UTC
(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
Comment 28 bugzilla2 2019-04-21 10:02:27 UTC
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
Comment 29 bugzilla2 2019-07-05 13:44:19 UTC Comment hidden (obsolete)
Comment 30 Timur 2019-10-09 14:29:52 UTC
(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.
Comment 31 Timur 2020-03-08 19:03:22 UTC
*** Bug 127428 has been marked as a duplicate of this bug. ***
Comment 32 Jürgen 2020-03-09 10:37:38 UTC
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.
Comment 33 bugzilla2 2020-03-09 10:45:09 UTC Comment hidden (obsolete)
Comment 34 Timur 2020-04-01 16:47:12 UTC
*** Bug 131745 has been marked as a duplicate of this bug. ***
Comment 35 b. 2020-04-04 22:56:09 UTC
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.
Comment 36 wdehoog 2020-05-15 11:53:25 UTC
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.
Comment 37 Timur 2020-05-15 14:22:07 UTC
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.
Comment 38 Timur 2020-06-10 14:27:35 UTC
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).
Comment 39 bugzilla2 2020-06-27 09:58:38 UTC Comment hidden (obsolete)
Comment 40 Buovjaga 2020-06-27 10:09:47 UTC Comment hidden (obsolete)
Comment 41 bugzilla2 2020-06-27 10:25:10 UTC
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
Comment 42 b. 2020-06-27 13:27:23 UTC
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'?
Comment 43 Telesto 2020-06-27 14:20:46 UTC Comment hidden (obsolete)
Comment 44 bugzilla2 2020-06-27 14:28:07 UTC
(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.
Comment 45 b. 2020-06-27 21:47:44 UTC
@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 ...
Comment 46 Buovjaga 2020-06-28 06:31:42 UTC
(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!/
Comment 47 Telesto 2020-06-28 08:49:02 UTC
(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.. )
Comment 48 bugzilla2 2020-06-28 14:13:13 UTC
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...
Comment 49 b. 2020-06-29 08:39:36 UTC
(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 ...
Comment 50 bugzilla2 2020-06-29 10:11:05 UTC
(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...