Created attachment 141323 [details]
The odf file for text to be pasted

Created attachment 141324 [details]
The pdf file for text to be copied from

No repro for both issues based on the steps in comment 0 (except I used PDF-XChange)
Version: 6.1.0.0.alpha0+
Build ID: 84e2614a75a615d6c8584b13a69b3368d2a12a3d
CPU threads: 4; OS: Windows 6.3; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-04-12_09:11:38
Locale: nl-NL (nl_NL); Calc: CL

But the bug exists for sure.. However I can't reproduce it reliably either. This works for me 1 out of 4 attempts or so (bug 116014)

1. Open attachment 141323 [details]
2. Disable spell check
3. Insert a comment -> Add some text: say "AAA"
4. Select "AAA' with the mouse
5. Right click -> Copy
4. Right Click after Line One -> Paste (enabled)
5. Add "B" to "AAA" in the comment box - so: "AAAB"
6. Select "AAAB" with the mouse
7. Right click -> Copy
8. Right Click after Line One -> Paste should be disabled..

Maybe a dublicate of bug 65606?

 “Bug not reproducible in version”
Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded

Hello Xisco,

I checked this on 
Version: 6.3.0.4 (x64)
Build-ID: 057fc023c990d676a43019934386b85b21a9ee99

1. The paste button being active when there is nothing in the clip board exists
2. the paste button getting deactivated after i copied text from the pdf exists


I could only paste after I closed and reopened Writer.

3. The formatting being reset to original after pasting is working as expected.

(In reply to Nithin from comment #10)
> 1. The paste button being active when there is nothing in the clip board
> exists
This is not the point of the bug. Only one bug per report and that's 2 here.  

> 2. the paste button getting deactivated after i copied text from the pdf
> exists
> I could only paste after I closed and reopened Writer.
No repro as described. But I did repro with 6.4+ first time I tried Telesto's steps, with simple comment text copy.
So I also conclude there's a bug, but we don't have reliable steps.

Thanks to https://bugs.documentfoundation.org/show_bug.cgi?id=57147#c28 I have steps for part of the bug when Paste button is deactivated.
Repro OO and LO 6.4+.

1. Open a new Writer Document. I reproduce when Writer is opened before copying.
2. Open Vivaldi or Opera or Firefox or PaleMoon and go to https://www.heise.de/newsticker/
3. mark and copy (CTRL + C) some newsticker headline (but ONLY the headline. Do NOT right-click the link and copy the link, but mark the text and copy the text. 
4. go to Writer and see that paste is unavailable - and that's the BUG
Note: I may paste the clipboard with CTRL + V. Often that's also not possible and some other steps are welcome. 

Many similar reports. I set to High hoping that this will draw someones' attention.

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

it seems a duplicate of bug 57147... anyway, let's keep it open for the the time being. no need to have both as high severity bugs though...

(In reply to Xisco Faulí from comment #15)
> How can you select the headline in Firefox? 
Simply with mouse from left to right. Takes some practice, though.
are you sure it doesn't work when using Firefox ?
Today I tried again and paste button was available on first copy (meaning no repro) but on the following copy button wasn't available (repro).

Xisco, did you reproduce? There are many paste-related bugs and now we have steps we should raise importance and get someone to look at this. 
Hopefully this can be done without a refactoring of the XClipboard per https://bugs.documentfoundation.org/show_bug.cgi?id=62196#c62.

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

I has the same problem in Calc, but sometimes happens sometimes not.
When I copy some text from another program and I try to paste in Calc, the buttons are disabled or the short cut doesn't work. But if I close the program and open a new sheet, I can paste the information I had copied previusly.
This bug has been ocurring for a long time and nobody fixit it.
I'm using Windows 10 and Calc 6.3.3.2.

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

If that can be of any help, I want to add some details regarding version 6.4.3 (running on ArchLinux)
Here the problem can be defined as : copy/paste between different documents opened in Writer (or among sections in the same document) stops working properly after some time.

Basically to recreate the issue simply :
- have a document with some text in it, open it
- select, then copy / paste a section of it in that same document, that works
- select, then copy / paste another section and repeat that with different sections (to be able to know if you're pasting the section you've just copied or the one before), until at some point either it pastes nothing (the icons on the top of LO are greyed in that case) or it pastes the previous selection. The length of the selection itself, or of the one before doesn't seem to matter (one word, two, one paragraph, more), then after some time, it will stop to reproduce and work again, then will stop working, etc... What resets it it stopping LO and starting it again, that makes it works perfectly fine for some time again and it appears again, etc...

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

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

I retested annoying paste issue. 

Reproduced Description and Comment 13 from bug 116983 in LO 6.3 as regularly no paste is available in toolbar and right-click menu, while Ctrl+V is working. Seems that LO (ex. new Writer) must already be open when text from PDF is copied. 
Easier to see if there's more text in some PDF, so you copy part1 from PDF and paste to Writer, then part2 or part3. Same with Adobe Acrobar or PDF-Xchange for me.
But I don't reproduce that in master 7.1+ which would be nice.

Similar with duplicated bug 116014, simple copy of "LibreOffice Design Blog" from https://planet.documentfoundation.org/ wouldn't work in already open LO 6.3 while would in 7.1+.

Created attachment 161838 [details]
Another PDF

1. Open a PDF - for example attachment 161838 [details] - with Adobe Acrobat Reader DC 
2. Select some text from the PDF in Acrobat & copy
3. Right Click Paste in Writer
4. Select some different text from the PDF in Acrobat & copy
5. Right click paste in Writer
6. Select some different text from the PDF in Acrobat & copy
 
-> Paste should show disabled by now; with CTRL+V still working properly

Actually: "no paste is available in toolbar and right-click menu, while Ctrl+V is working" and CTRL+SHIFT+V also not working (nor working "paste unformatted text" custom icon). 
So bug 65606 really can be the same.

Another version
1. Download Insideclipboard
2. Open Calc
3. Open notepad and type some text: say AAA
4. Clear clipboard with Insideclipboard
5. Copy AAA
6. Right Click Paste in Calc

(In reply to Telesto from comment #32)
> (In reply to Timur from comment #29)
> > Telesto, which is your test LO version?
> 
> Version: 7.1.0.0.alpha0+ (x64)
> Build ID: 59939d2490726336546c7ad05082d23031074e12
> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win

Mine is the same. If you still reproduce, I'm wrong this is resolved. 
But at least seems much better than 6.3, like there were some changes.

(In reply to Timur from comment #26)
> This is Win and I can't make bibisect, which would be very useful to confirm.

Xisco and Buovjaga: please see and maybe try to reverse bibisect this.

Bug 57147, bug 65606, bug 116983 look similar: 
"Paste is sometimes deactivated in toolbar and context menu and Paste Special CTRL+SHIFT+V isn't working. Text is copied to clipboard and CTRL+V and CTRL+ALT+SHIFT+V are functioning."
Bug is surely and mostly in Windows, but some reports are also for Linux. 
I can easily reproduce in LO 6.3 and LO 7.0 beta in Windows, with copying from PDF like attachment 161838 [details] (using Adobe Acrobat or PDF-Xchange) or web page like title from https://planet.documentfoundation.org/, so steps are rather reliable, but not so in master 7.1+. 
I was hoping that this was resolved, but other user reproduced again.
Normally we duplicate and merge bug reports but we have 19 reports and 31 CCed users (plus those in duplicated reports), it would be a lot of messages. 
It's of highest importance, even not of severity, to resolve these.

(In reply to Telesto from comment #31)
> Another version
> 1. Download Insideclipboard
> 2. Open Calc
> 3. Open notepad and type some text: say AAA
> 4. Clear clipboard with Insideclipboard
> 5. Copy AAA
> 6. Right Click Paste in Calc

I tried to reverse bibisect this as I don't get this with a Win master build, but got a nonsensical result. Used the new Win 7.1 repo. The latest commit in the 7.1 repo is consistently working, though.

It would be great if this is resolved, although it will take long to arrive in release in 7.1. I don't know how Telesto still reproduces. We may keep open because there may be more duplicates.

(In reply to Timur from comment #38)
> It would be great if this is resolved, although it will take long to arrive
> in release in 7.1. I don't know how Telesto still reproduces. We may keep
> open because there may be more duplicates.

I would love somebody to try comment 28 and the paste from comment from separate instance of LibreOffice (bug 133533). Yes, the second one is not a real life example.. but need it to be? Surely not a different bug. 

The only thing I care about is a confirmed reproducer.... Which still holds on 7.1 - there is IMHO. And a developer who takes a peak at it.. if we finally have some way to 'proof' the issue

I reported this in separate reports, to get a conformation or/not.. but it gets marked as duplicate without testing.. or tested and still marked as duplicate of some related bug without STR.. And the opinion changed to 'I don't see this anymore'. Without knowing any testing steps (there a multitude of steps around). Some bugs need very exact steps.. like bug 133975 (appearing, disappearing. reappearing.. superficial bibisects point to Jan-Marek, he gets the blame, and his commits did make it worse.. but the culprit being somewhere else)

Marking everything rigorously as a duplicate makes it difficult to keep track.  And the paste disabled in context menu is a facet of the copy/paste bug mess. Paste being blocked has probably a different cause. Pasting older copy.. another..

I prefer starting with stabbing the he copy context menu/ ctrl+shift+paste issue (for Windows).. The easiest to reproduce, as far I know... And look for other issues afterwards. The copy/paste bugs should be tackled step by step.

(In reply to Buovjaga from comment #37)
> (In reply to Telesto from comment #31)
> > Another version
> > 1. Download Insideclipboard
> > 2. Open Calc
> > 3. Open notepad and type some text: say AAA
> > 4. Clear clipboard with Insideclipboard
> > 5. Copy AAA
> > 6. Right Click Paste in Calc
> 
> I tried to reverse bibisect this as I don't get this with a Win master
> build, but got a nonsensical result. Used the new Win 7.1 repo. The latest
> commit in the 7.1 repo is consistently working, though.

I was discussing the general clipboard topic a bit in the dev chat and was pointed to this commit:
https://git.libreoffice.org/core/+/fda6ad1458fcd5087c3dde56300b9d0367af6db5%5E%21
cache foreign content in win32 clipboard code (tdf#133267)

I checked the Win 7.1 repo and unfortunately this specific commit is inside a range of commits! So it might be that this commit helped solve this particular issue.

(In reply to Buovjaga from comment #40)
Nothing changed.. the clipboard still gets 'borked' somehow. 

1. It works until it break down.. if breaks it gets unpredictable, until it returns to normal.  
2. The copy comment content from LibreOffice instance LibreOffice 7.0 b2 to master still breaks down after (copy/pasting pattern of 3/4 times). Writer/Calc no difference. Copy/Paste from Adobe acrobat reader start fail too, after the brokenness is introduced

New document doesn't solve the problem; clipboard is disable.. 

Version: 7.1.0.0.alpha0+ (x64)
Build ID: 43c60ce1ac7629a1462e927e6ff937469f58f743
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

This is a OOO bug, IMHO. So appears goes, away, appears etc. so bibisecting is pointless exercise.

(In reply to Telesto from comment #41)
> (In reply to Buovjaga from comment #40)
> Nothing changed.. the clipboard still gets 'borked' somehow. 
> 
> 1. It works until it break down.. if breaks it gets unpredictable, until it
> returns to normal.  
> 2. The copy comment content from LibreOffice instance LibreOffice 7.0 b2 to
> master still breaks down after (copy/pasting pattern of 3/4 times).
> Writer/Calc no difference. Copy/Paste from Adobe acrobat reader start fail
> too, after the brokenness is introduced
> 
> New document doesn't solve the problem; clipboard is disable.. 
> 
> Version: 7.1.0.0.alpha0+ (x64)
> Build ID: 43c60ce1ac7629a1462e927e6ff937469f58f743
> CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
> Locale: nl-NL (nl_NL); UI: en-US
> Calc: CL
> 
> This is a OOO bug, IMHO. So appears goes, away, appears etc. so bibisecting
> is pointless exercise.

I was talking about the variant involving using InsideClipboard to clear the clipboard. You still repro it with master?

(In reply to Buovjaga from comment #42)
> I was talking about the variant involving using InsideClipboard to clear the
> clipboard. You still repro it with master?

Yes, when copy/pasting from a comment note from LibO instance a to LibreOffice instance B.. And if it's broken.. it will affect other copy/pastes for a while

(In reply to Telesto from comment #43)
> (In reply to Buovjaga from comment #42)
> > I was talking about the variant involving using InsideClipboard to clear the
> > clipboard. You still repro it with master?
> 
> Yes, when copy/pasting from a comment note from LibO instance a to
> LibreOffice instance B.. And if it's broken.. it will affect other
> copy/pastes for a while

Just want to make things super duper clear, as I am looking at these steps, which have nothing to do with comments and different LibO instances:
1. Download Insideclipboard
2. Open Calc
3. Open notepad and type some text: say AAA
4. Clear clipboard with Insideclipboard
5. Copy AAA
6. Right Click Paste in Calc

I just tried again and I can consistently reproduce with 6.4.4, but NEVER with master. So on my system this case is WFM. I'm not saying Nithin's original report is WFM as I didn't try it.

I already wrote that I find Telesto's LO instances argument wrong for troika 
Bug 57147, bug 65606, bug 116983.
Because:
1. these are real usage bugs and not theoretical
2. at least one instance is probably older LO.

I suggest Telesto reopens some of his bugs for LO instances and tests with two fresh master instances and that we close these.  
Buovjaga, please confirm and I'll do.

As for Nithin's Comment 0:
Even if we clear clipboard, say with ‘echo off | clip’ (no quotes) in Win CMD, Paste is active. I wouldn't consider it a bug and is not this one. 
Paste bug in step 7 is the same as other paste issues from PDF, WFM now in LO master.

(In reply to Timur from comment #45)
> I already wrote that I find Telesto's LO instances argument wrong for troika..

1) You need a reproducer.. It does exactly what is described.. Working until it suddenly stops. And successive copy/paste from other apps to LibreOffice go off track  after such an event.. And the problem is limited to LibreOffice (copy/paste is functional). And if this also happens between master builds using the system clipboard, it's still means something is off. Between LibreOffice instances (same master version) it should work. I you never know where the issue is when pasting from Firefox/Chrome.. Could be a Firefox/Chrome bug..

It is not explicitly relevant 'how' it reproduced.. that there is a reproducer which fits the description and can be reproduced... in contrast to many many other reports.. This could be 'timer' based or solar mutex being lock/unlocked. So depending content & some quirky timing. 

2) Closing this bug; no complains issue

3) Would like bug 57147; bug 65606 being closed also.. maybe after someone asking if the issue is resolved with 7.0/ 6.4 (not sure where the 'good' starts)
 
4. Leave my 'lovely' troika case open.. and lets wait if some new come in (hopefully not). I acknowledge there is some improvement.. or the problem is better hidden. However have seen it happen - again while testing copy/pasting.. in a different setting. Without registering the steps (if this possible at all). And of course being sporadic It could be caused by how order of of clipboard formats. So pure text, against RTF, against HTML and or timing etc. Way to many variables.

Another (dubious?) way based on bug 99623
1. Download CLCL https://www.nakka.com/soft/clcl/index_eng.html
2. Run it
3. Copy three snipped plain text from this bug doc or bug 99623
4. Open Writer
5. Check the Right Click context menu in Writer (working)
6. Change the snippet on the clipboard with CLCL by click in the Deskbands in the task bar and click on CLCL icon and pick a different item
7. Repeat 5 -> Probably already disabled.
8. Else repeat it 2/3 times.. with some different content..

(In reply to Nithin from comment #0)
> Description:
> The paste options under, Edit-Paste, Edit-Paste_Special and
> Right_Click-Paste, Right_Click-Paste_Special are deactivated even though
> text is copied to clipboard.
> 
> Steps to Reproduce:
> 1.Clear clip board in your OS. There should not be anything copied into the
> clipboard.
> 2.Open pdf and odt flie.
> 3.Right click at the end of Line One in the odt file
> 4.Paste is active even though nothing is in clipboard(There is nothing to
> paste.)(This is the first bug)(Do click on paste to verify that clipboard is
> really empty)
> 5.Shift to the Pdf file and Copy the text(I did it with Right_click Copy in
> adobe reader).
> 6. Shift back to the odt file. Right click and try pasting the copied
> contents.
> 7. This is Bug2. The options Paste and Paste special are greyed
> out(deactivated). It is however possible to paste using keyboard
> shortcuts(Ctrl+V or Ctrl+Shift+V)

I don't reproduce either bug1 or bug2 with 6.4.4 or master on Win 10. Used InsideClipboard to clear and Adobe Reader for PDF.

I don't think it's good to pile on variations from different reports in this one.

I'm going to put this in needinfo and kindly ask Nithin to test with a fresh master https://dev-builds.libreoffice.org/daily/master/current.html Win-x86_64@tb77-TDF

Bug 57147 (Win), bug 65606 (Win and Lin), bug 90120 (Win), bug 99818 (Lin), bug 116983 (Win) look similar: 
"Paste is sometimes deactivated/greyed in the toolbar and context menu and Paste Special with CTRL+SHIFT+V isn't working. 
Text (from PDF or web) is copied to clipboard and CTRL+V and CTRL+ALT+SHIFT+V are functioning."
There can be differences, though. One reports that even Ctrl+V isn't working.

It's a lot of reports and random behavior, so single reporter with so many duplicates is not relevant per se. 
I think we should wait for 6.4.5.2 and than ask all to upgrade and test and in addition to test daily master. 
And than close with hopeful positive feedback, taking into account Win and Lin and shortcut behavior.

@b
The whole copy/paste disabled issue is spread around some bug reports :-(
Would you mind testing comment 47 and/or this one:


Have two instances of LibreOffice; run them in parallel (ideally 2x master or b2 or something like that. Else the internal clipboard will be used.. but the problem is with the 'external' system clipboard. 

1. Open attachment 141323 [details] in instance A
2. Insert a comment -> Add some text: say "AAA BBB CCC"
3. Select "AAA' with the mouse
4. Right click -> Copy
5. Go to second instance (B) -> Right click paste -> Working
6. Repeat 3-5 (3x).. Paste should be disabled.. (maybe changing the selection to BBB)

(In reply to Telesto from comment #53)
> @b
> The whole copy/paste disabled issue is spread around some bug reports :-(

it's old and it's nasty :-( :-( :-(

but it should be eradicated shortly as it's severely undermining LO's 'user experience' ... "what is this program, can not copy and paste?" 

A.) > Would you mind testing comment 47 

afaics that's installing some helper program, i don't see any sense in that, on the one hand libreoffice should first learn to handle the normal clipboard, and then you never know after such installations whether malfunctions on the computer are caused by this installation or by remnants of it ... 

B.) > and/or this one:
> 
> Have two instances of LibreOffice; run them in parallel (ideally 2x master
> or b2 or something like that. Else the internal clipboard will be used.. but
> the problem is with the 'external' system clipboard. 
> 
> 1. Open attachment 141323 [details] in instance A
> 2. Insert a comment -> Add some text: say "AAA BBB CCC"
> 3. Select "AAA' with the mouse
> 4. Right click -> Copy
> 5. Go to second instance (B) -> Right click paste -> Working
> 6. Repeat 3-5 (3x).. Paste should be disabled.. (maybe changing the
> selection to BBB)

tried it, had much fun, 'copy' in right click menu for text in comment not available, used strg-c for it, worked fine besides paste in writer got a paragraph mark added after every 'AAA' 'BBB' or 'CCC', also tried from 'AAA BBB CCC' added as text on the sheet, 'AAA' was pasted as ' AAA' - with an additional space in front, same for 'BBB' but not for 'CCC' ... please do NOT! ask if i accidentally had a space included in the copy source ... did some dozen copies, pastes and paste specials, no problems except the formatting shortcomings described. imho they are a hint for confused code. 

C.) regarding 'internal' and 'external' clipboard i tried something further, as this bug description asked to 'empty clipboard' before repro-test i looked for something to do this / check clipboard content, tried a little utility 'insideclipboard' and had the following fun copying from opera - heise newsticker to writer: 

- sometimes - i think it was with writer 6.3.6.1 - on copy of a headline insideclipboard was emptied, but i could paste in writer (forgot to test if paste in other prog. would work), 

- reproducibly the copy (ctrl-c) and then paste (ctrl-v) of a headline to writer 7.1 was pasted 'in color' (light blue) on the first try (newly marking a headline), and in 'grey' if i reactivated the opera window with the still marked headline, pressed ctrl-c without any other action on that window, changed to writer and pasted, 

- and just now did a short recheck, on the eleventh copy - paste of alternating a newly marked headline and a repetition of it in grey neither paste nor paste special work ... 

- and subsequent opened writer 6.3.6.1, copied a fresh marked headline and pasted it, coloured but 'insideclipboard' shows clipboard as empty, subsequent copy of the same marked headline fills insideclipboard with content and pastes in grey into writer, 

assumption ... from behaviour and snippets here and there in bugs ... there are more than one procedure for 'clipboarding', 'external' (normal windows) and 'internal' (invented because 'standard' couldn't fullfill all of LO's requirements?) and they work in competition, or sometimes 'race condition', and results are unpredictable as no programmer or user can decide which wins which part of the cake at what time? ... just an assumption, sorry @Eike, 

regarding exact this bug: 

> 1.Clear clip board in your OS. There should not be anything copied into the clipboard.
did with 'insideclipboard', 
> 2.Open pdf and odt flie.
opened 'files', 
> 3.Right click at the end of Line One in the odt file
> 4.Paste is active even though nothing is in clipboard(There is nothing to 
> paste.)(This is the first bug)(Do click on paste to verify that clipboard is 
> really empty)
norepro, paste options grey, 
> 5.Shift to the Pdf file and Copy the text(I did it with Right_click Copy in 
> adobe reader).
ok, 
> 6. Shift back to the odt file. Right click and try pasting the copied 
> contents.
> 7. This is Bug2. The options Paste and Paste special are greyed 
> out(deactivated). It is however possible to paste using keyboard 
> shortcuts(Ctrl+V or Ctrl+Shift+V)
repro! 

setting 'new' as at least a part of this flavour of bug remains, 

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

and a last recheck ... having only writer 7.1 open for the test from OP worked fine longer than i liked to invest time, opening writer 6.3.6.1 in parallel brought both error conditions (clipboard empty, paste works, clipboard filled, paste grey) in both writer ver. after short time ... 

and the very last: only writer 7.1, first try to paste copy from adobe doesn't work with any option, not even with ctrl-shift-alt-v, 

one armed bandit's are! easier ... 

P.S. consider i lived with theese bugs without taking notice for years! i had some nastinesses sometimes but found a workaround and concentrated back to my normal work, the danger from this bug is tolerable as a user mostly recognizes that something went wrong and corrects it, but ... what a poor picture ... 

just to countercheck win problems i'd run 'sfc /scannow', found some pending renames, restarted system, headline copying from opera - heise newsticker to writer 7.1, four attempts ok, all in colour! :-) , fifth failed :-( , cleared clipboard content, copied again, pasting works ... grey ... 

women are complicated - i love! women, cars are complicated - i love! cars, computers are complicated - i love! computers, one-armed bandits are complicated - i love! one-armed bandits, LibreOffice is ... let's talk about something else ... 

@Timur: 'So I also conclude there's a bug, but we don't have reliable steps.' ... we neither have a reliable program ... and it's a little overtuned to expect reliable fails from an unreliable program ...

Created attachment 163026 [details]
Inside Clipboard file

1. Download https://www.nirsoft.net/utils/insideclipboard.zip
2. Download the attached file
3. Open Inside Clipboard 
4. File -> Clear all clipboard data (Inside Clipboard )
5. Launch Writer
6. Right Click in side the document -> Disabled -> Fine
7. File -> Load .CLP -> attached file
8. Right click inside the Writer document -> Paste enabled (fine)
9. File -> Clear all clipboard data (Inside Clipboard )
10. Right Click in side the document -> Disabled -> Fine
11. File -> Load .CLP -> attached file
12 Right click inside the Writer document -> Paste enabled (fine)
13 File -> Clear all clipboard data (Inside Clipboard) 
14. File -> Load .CLP -> attached file
15 Right click inside the Writer document -> Paste disabled(wrong)

-> Sometimes it happens on the second time already

hello @Telesto, 

i tried to rework your recipe, with 6.1.6.3 you get a very strange file with a lot of ASCII garbage, sample: 

'MCS0/#####TABELA DE DESEMPENHO RF
Potˆncia de transmissÆo m xima (dBm)'

not the AAA BBB CCC DDD i expected, with 7.1.0.0.a0+ - which is the only which makes sense to test - i get: 

'The file 'ABCD.clp' is corrupt and therefore cannot be opened. LibreOfficeDev 7.1.0.0.a0 2020-07-10 can try to repair the file.

The corruption could be the result of document manipulation or of structural document damage due to data transmission.

We recommend that you do not trust the content of the repaired document.
Execution of macros is disabled for this document.

Should LibreOfficeDev 7.1.0.0.a0 2020-07-10 repair the file?'

and after clicking 'yes': 

'The file 'ABCD.clp' could not be repaired and therefore cannot be opened.' 

'it will get worse before it gets better'? or

'don't think you're at rock bottom, there is always a way further down.'?

(In reply to b. from comment #56)
> hello @Telesto, 
> 
> i tried to rework your recipe, with 6.1.6.3 you get a very strange file with
> a lot of ASCII garbage, sample: 
> 
> 'MCS0/#####TABELA DE DESEMPENHO RF
> Potˆncia de transmissÆo m xima (dBm)'
> 
> not the AAA BBB CCC DDD i expected, with 7.1.0.0.a0+ - which is the only
> which makes sense to test - i get: 
> 
> 'The file 'ABCD.clp' is corrupt and therefore cannot be opened.
> LibreOfficeDev 7.1.0.0.a0 2020-07-10 can try to repair the file.

You are supposed to open the .clp file with Inside Clipboard, not LibreOffice.

(In reply to @Buovjaga from comment #57)
 
> You are supposed to open the .clp file with Inside Clipboard, not
> LibreOffice.

*ROFL*, how could i have been that stupid ... *LOL*, thanks, you made my day ... 

for the records: nice reproducibility! 

(small hope, may be the receipt wasn't 120% accurate ... but even if ... nice error *lol*)

@Mike Kaganski
Any change to get you so crazy to look as this :-). It appears we have reproducer; finally (comment 55). A nasty one to track down; 

Paste is sometimes disabled (under Windows). Not over the full line, but only for 'active documents'. So paste not working in a open writer document. However it works fine in a new document. 

This is lovely thing is already happening since 3.3.0. And I hope it's related to/ also causing the 'pasting' prior content bug. Because the paste is stopped working once, it often bit odd on sub-sequential copy/paste before normal function is restored. 

Anyhow, paste / Paste RTF being disabled frustrating enough and enough reports about it.

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

This bug is really awful, the worst I've run into for LO yet. I can reliably reproduce it in 7.1. Does anyone have suggestions on ways to mitigate it / reduce its frequency while we wait for a fix?

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

(In reply to Telesto from comment #63)
> Bumping to major.. CC list growing Bug 65606 and this one

The severity does not magically grow with the interest. You're thinking of priority, which is already highest.

Buovjaga, what are the criteria for severity?

I only ask b/c I'm hoping this bug is treated very seriously, but I'm a bit pessimistic given how long it's been around. It's the first bug which has made me think, "Maybe I went wrong opting for LibreOffice rather than Word," and I've used OpenOffice and then LibreOffice for about 10 years now. I know that LibreOffice doesn't have the same support capacity--that's a tradeoff for it being free-but I hope this bug is indeed prioritized in upcoming releases.

https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Buovjaga is right, Importance is OK, bug is the problem, for which there were no volunteers to fix. 


(In reply to Apt from comment #61)
> I can reliably reproduce it in 7.1. 
That's important, because I tested improvement in master 7.1+. Please write exact version (to know the date) and OS you use (Win and Lin different) and steps you use.

Thanks for the response, Timur. Here is the info:

LO version: 7.0.1.2 (x64)
-Apologies that I referred to it as 7.1 earlier. I was mistaken. To my knowledge, 7.0.1 is the latest release version.

OS: Windows 10

Steps to reproduce:
1) Open my notepad .txt.
2) Open three .odt files with Writer.
-In case the doc sizes are a factor, the .odt's are ~800kb, ~360kb, and ~220 kb respectively.
-In case it's relevant, I normally keep the notepad .txt on the first monitor and the .odt's on the second monitor.
3) Continue to copy selections from the .txt and paste them to the .odt. It has become normal for the paste to fail within 5-10 iterations of this process (with the context menu in LO indicating that it's like nothing is currently copied, although I can still paste in notepad what is currently copied from the .txt).
4) Once the issue crops up, my workaround is to repeatedly copy the selection in the .txt until LO registers the copy, but it's unpredictable when LO will actually do so. Sometimes it only takes one re-copy. Sometimes it takes five re-copies. I think time might be a factor here.

For clarification:
Q1) Is the fix already verified as working in 7.1 master?
Q2) If yes to Q1, the fix coming to the 7.0 branch?
Q3) If no to Q2, when can we expect the first release of 7.1?

As you can tell, I'm quite anxious for the fix. This abominable bug has been plaguing me even more frequently as of late.

(In reply to Apt from comment #68)
> For clarification:
> Q1) Is the fix already verified as working in 7.1 master?

The only way to find out is to test it yourself:
https://dev-builds.libreoffice.org/daily/master/current.html (Win-x86_64@tb77-TDF)

The daily build installs separately

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

Alas, Telesto, right you are about its still being broken. I just tried the 7.1.0 beta, and sure enough, within a few attempts at copying and pasting from Notepad the issue had already cropped up. Will no one rid us of this turbulent bug? I have some coding experience but none in LibreOffice dev...

Hello, 

I also confirm this. 

It does not only affect text, at times no images can be inserted.
 
It appears that the operating system clipboard is not recognized. 

Copy and paste within the Office application (e.g. from Writer to Calc) works. 

Version: 7.0.4.2 (x64)
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL

Windows 10 Pro 20H2

Reset User Profil = Yes

This is greatly impacting my users as well. Here is a simple way to observe:

1. Open Writer (or Calc) and Windows Notepad. Position the two windows so you can see them both onscreen.
2. Type the word "test" in Notepad and select it.
3. Press Ctrl+C in Notepad.
4. Notice that the Paste toolbar button in Writer (or Calc) becomes enabled.
5. Repeat pressing Ctrl+C in Notepad several times with a 1 second delay between each press while observing Writer (or Calc) toolbar.
6. A large percentage of the time the Paste button becomes disabled. This is incorrect because the clipboard does contain the data.

Usually Ctrl+V works correctly to paste the data even though the toolbar button does not indicate that paste is possible. Unfortunately, even this workaround fails often enough to be problematic.

Toggling the Windows 10 clipboard manager (Settings > Clipboard > Clipboard history) does not help.

The problem even occurs in the current latest RC (7.1.0.2).

See also bug 139084.

The problem is severe for users whose workload involves a lot of copying and pasting data from other applications. It is worst for those users who are uncomfortable with keyboard shortcuts.

Version: 7.1.0.2 (x64) / LibreOffice Community
Build ID: 53d68d29d90fd16448721a60aad68c28ff0809f5
CPU threads: 12; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

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

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

Created attachment 169641 [details]
ClipboardTest.cpp code that provokes the problem

This is happening because only one application can be within OpenClipboard/CloseClipboard at the same time. LO calls OleGetClipboard which uses OpenClipboard/CloseClipboard internally. Per https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-openclipboard "OpenClipboard fails if another window has the clipboard open." This can probably happen easily as various applications receiving the WM_CLIPBOARDUPDATE notification each try to examine the clipboard simultaneously.

This seems to explain why Ctrl+V usually works even when the toolbar/context menu is grayed out. It possibly explains why there are times, although infrequently, when even Ctrl+V does not work.

For an example of a workaround implemented by Microsoft, see this code which synchronously retries 10 times with a delay of 100 ms between each attempt. (See https://github.com/dotnet/winforms/blob/main/src/System.Windows.Forms/src/System/Windows/Forms/Clipboard.cs)

Note that reading the clipboard is not the only susceptible operation; others that LO calls (OleSetClipboard, OleFlushClipboard) can fail too. This coincidental timing sounds less likely, but apparently there are apps that can provoke errors on setting the clipboard too. Sounds like one of them is Windows's Remote Desktop clipboard support, so those may be important to fix as well. Some of the references given below cover this.

* Doesn't happen on your system (using my repro procedure from comment 78)?

Use the attached ClipboardTest.cpp program. It contains a Sleep(500) during OpenClipboard/CloseClipboard which should be more than enough to provoke the problem. The problem often happens for me even with this sleep is omitted.

* Happens on your system?

If you use the attached program with the Sleep(500) commented out, it will often print the hwnd of the program causing the problem on your system.

Info from others:
https://blog.somewhatabstract.com/2012/06/27/when-the-clipboard-says-no/
https://stackoverflow.com/questions/1859102/how-can-i-fix-cannot-open-clipboard-access-denied-errors
https://stackoverflow.com/questions/68666/clipbrd-e-cant-open-error-when-setting-the-clipboard-from-net
https://bugreports.qt.io/browse/QTBUG-27097

hurray ... !!! 

this sounds as if after 10 years less 13 days (35499 is the oldest related bug i noted yet) and 61 bugs (i noted yet) someone spoke who knows what he's talking about, 

@jasonkres: pls. mail me your bank account - !in private! - and be sure to get a 500 bucks price / reward / donation once this problem is solved, 

@anydeveloper: do the same and get the same once you are the first to provide a working solution, 

(conditions for developers: the price is paid only once, voluntarily, according to my decision and under exclusion of legal recourse, the solution must be comprehensive and prove itself for 3 months, it must be clearly defined and clearly and comprehensively commented so that it can also be understood by 'half laymen', it must be 'smart' and avoid brutal action as described under 'race conditions'.)

special thing i see in the man (or woman?) who spoke: 'not afraid to dive into M$ stuff!', 

'race condition' sounds as such might lead to actions like users of a SBS with limited access slots reserving them in the morning and thus blocking others, or like 'if we don't get a response we just knock more often' and if more users do that the system breaks down, imho LO shouldn't act that way, 

CSMA/CD - https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_detection - (in the old days when we did ethernet with antenna cable) was a smart way to deal with such problems ...? 

happy to see hope ... :-)

(In reply to b. from comment #82)
Fingers crossed that this fix might - even by incident - fixes the issue here: https://gerrit.libreoffice.org/c/core/+/109829

(In reply to Telesto from comment #83)

The problem remains in:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 62dff2844b0bf1d1bcb8eb4d6db529ef4a31bee4
CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

As tested using the procedure in comment 78 while the comment 81 attachment 169641 [details] program is running at the same time. Note the problem also reproduces on my particular system as before, even without using that test program to aggravate it further.

Other programs are allowed to briefly lock the clipboard. When any of the following Windows APIs give a failure code it has to retry several times in a blocking loop (Microsoft code that I referenced in comment 81 does 10 additional retries with 100ms between each try) or kick off a retry timer to do the retries. LO doesn't do that, so its clipboard code is just not correct and robust. (Dumb Windows design, but it is what it is... probably because the design originated in the cooperative multitasking days when the current task would not normally be switched while it is between the OpenClipboard and CloseClipboard calls.)

OpenClipboard
OleGetClipboard
OleSetClipboard
OleFlushClipboard
(not guaranteeing this is the complete list...)

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/cf1c835e8016f8f1eefea6d625a913c0ac343a63

tdf#116983 tdf#136175: retry if failed

It will be available in 7.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Thanks Mike. As per https://bugs.documentfoundation.org//show_bug.cgi?id=116983 "best would be to close also that one, and in case when another problem appears, just have a new clean issue"

Please test windows master build: https://dev-builds.libreoffice.org/daily/master/current.html

For remaining problems please file a new bug.

Correct reference to Mike's comment: https://bugs.documentfoundation.org//show_bug.cgi?id=136175#c4

(In reply to steve from comment #86)
> Please test windows master build:
> https://dev-builds.libreoffice.org/daily/master/current.html

... but only when it's updated to a point after the commit, i.e. after 2021-03-03 10:30:53 UTC.

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/316bebbbbd19cdccde05eba5f6098d301f032df2

tdf#116983 tdf#136175: retry if failed

It will be available in 7.1.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

I've verified that the fix corrects the issue (using Comment 78 procedure). Thank you so much Mike!

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: fbaea1013cc5781805254edc8830c1e46f46bd72
CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

(In reply to jasonkres from comment #90)

Thank you! The fix is implementing *your* strategy. You are mentioned as co-author there (hope that's OK).

I tested it in the most recent development build of 7.1.3 and ran into the same issue within the first several tries: I could copy from Notepad and LO's own clipboard would be empty. I will try it with 7.2 since jasonkres says it was working correctly on that version.

Version: 7.1.3.0.0+ (x64) / LibreOffice Community
Build ID: e83670cfb0184aa6719df15546bbd909554491d2
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

(In reply to Apt from comment #92)
> I tested it in the most recent development build of 7.1.3 and ran into the
> same issue within the first several tries: I could copy from Notepad and
> LO's own clipboard would be empty.

Hmm, this is unexpected. The commit mentioned in comment 89 should fix that in 7.1 branch since 7.1.2, and that commit is in the version you used ( see log at https://git.libreoffice.org/core/+log/e83670cfb0184aa6719df15546bbd909554491d2/ ).

(In reply to Apt from comment #92)
> I tested it in the most recent development build of 7.1.3 and ran into the
> same issue within the first several tries: I could copy from Notepad and
> LO's own clipboard would be empty. I will try it with 7.2 since jasonkres
> says it was working correctly on that version.
> 
> Version: 7.1.3.0.0+ (x64) / LibreOffice Community
> Build ID: e83670cfb0184aa6719df15546bbd909554491d2
> CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL:
> win
> Locale: en-US (en_US); UI: en-US
> Calc: CL

To get few things straight: 
1) are we talking about Writer or Calc?
2) Is this with or without Windows 10 "clipboard history" turned on? If enabled, what happens if you disable it?  
3) If step 2 doesn't deliver: Which application are running in the background?

1) Writer.
2) Windows 10 clipboard history has been off.
3) Besides LO Writer, basically just Chrome, Notepad, and Windows Explorer. Some background ones include Dropbox, "Logitech Gaming Software", "Radeon Settings".

Still testing with LO Dev 7.1.3. After restarting the computer today, I tried replicating the issue and couldn't. But I successfully replicating again while I had Chrome open.

Restarted the computer one more time and tried replicating again. Got it to happen again. This time Chrome was not open when the issue occurred.

I still have yet to test with 7.2, but I'll do that soon.

So far I can't replicate it in 7.2. Hopefully it stays that way!

Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: d97528da0c70c43fccd3239cbe8e064c3480bba8
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

(In reply to Apt from comment #92)
> I tested it in the most recent development build of 7.1.3 and ran into the
> same issue within the first several tries: I could copy from Notepad and
> LO's own clipboard would be empty.

I was able to reproduce this locally; and turned out that this was fixed by tdf#140813 on master.

I have backported the fix to 7-1 branch now, so hopefully a 7-1 release (7.1.3?) will get the fix, too.