Bug 136762 - LibreOffice does not paste after v7
Summary: LibreOffice does not paste after v7
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL: https://youtu.be/309DiYn5J0k
Whiteboard: target:7.2.0 target:7.1.3
Keywords:
Depends on:
Blocks: Paste
  Show dependency treegraph
 
Reported: 2020-09-14 22:55 UTC by BikeHelmet
Modified: 2021-06-05 10:32 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
InsideClipboard - Contents Example (7.35 KB, image/png)
2020-09-25 09:24 UTC, BikeHelmet
Details
InsideClipboard - Contents Example (4.37 KB, image/png)
2020-09-25 09:24 UTC, BikeHelmet
Details
InsideClipboard clp+ (5.31 KB, application/octet-stream)
2020-12-11 11:01 UTC, Andrew
Details
InsideClipboard clp- (5.31 KB, application/octet-stream)
2020-12-11 11:06 UTC, Andrew
Details

Note You need to log in before you can comment on or make changes to this bug.
Description BikeHelmet 2020-09-14 22:55:26 UTC
Description:
Paste is no longer a feature in Calc on my computer.

Steps to Reproduce:
1. Reboot computer.
2. Open LibreOffice Calc.
3. Open a website.
4. Copy some text or a forum post.
5. Go to LibreOffice and try to paste. Try the menu, try right-click -> Paste, try Ctrl+V and Ctrl+Shift+V
6. Go to Notepad++ and paste the text, no problem.
7. Go to Notepad and paste the text, no problem.
8. Copy the text from Notepad++ and from Notepad.
9. Go to LibreOffice and try to paste. Try the menu, try right-click -> Paste, try Ctrl+V and Ctrl+Shift+V

Actual Results:
Nothing pasted into Calc.

Expected Results:
Clipboard contents pasted into Calc.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
You can highlight the text and drag-and-drop it into Calc, but Paste itself doesn't work. Bizarre.

If I downgrade to v6.4.x it seems to work again, though pasting does break repeatedly after a couple pastes, and then is fixed by saving and using "Reload" on the document/spreadsheet.

I do have Ditto installed - a possible factor, though it does not interfere with anything else. I have tried turning it off and got the same results.
Comment 1 V Stuart Foote 2020-09-15 16:50:51 UTC
OP says clipboard holds content made available to other applications. Just not picked up for paste into a LO calc cell.

So Needinfo to OP as to the same content copied--but then behavior of LO Paste or Paste Special into a different LO module, i.e. Writer or Impress?

Maybe use a clipboard utility (e.g. Nirsoft's InsideClipboard) and see what formats your Windows shell is holding on the clipboard, and the priority--done with and without the 'Ditto' utility enabled.

Suspect to be a dupe of bug 62196, don't think there has been an substantive work on clipboard contents 6.4 -> 7.0

@Mike K.?
Comment 2 Mike Kaganski 2020-09-15 16:53:22 UTC
(In reply to V Stuart Foote from comment #1)
> don't think there has been an substantive work on clipboard contents 6.4 -> 7.0

That is also my perception.
Comment 3 BikeHelmet 2020-09-25 09:24:09 UTC
Created attachment 165828 [details]
InsideClipboard - Contents Example
Comment 4 BikeHelmet 2020-09-25 09:24:44 UTC
Created attachment 165829 [details]
InsideClipboard - Contents Example
Comment 5 BikeHelmet 2020-09-25 09:39:44 UTC
So I have been digging into it, and it seems almost like LibreOffice doesn't initialise something required for pasting until later. My workflow involves opening a document and pasting data into it, and something snags that up.

I happened to leave a spreadsheet open over lunch - before lunch it wasn't pasting the clipboard contents, and I was getting ready to retype the info. After lunch it worked fine.

Investigation: I opened a new document and tried to paste some text (CF_TEXT, CF_UNICODETEXT), some gmail HTML (HTML Format), paste special, etc. - absolutely nothing. Then I waited. And waited. After about 5 minutes, a green progress bar appeared at the bottom of the window and flashed by, and suddenly pasting worked again. It closely resembled the Save progress bar, which made me wonder if I just witnessed it autosaving.

So to test that, I opened another spreadsheet and made some changes and told it to save... no green progress bar. No save. I tried the menu, Ctrl+S hotkey, etc. - nothing happened despite the spreadsheet having been modified. Then after a while a green progress bar appeared, the file modified date changed in explorer, and suddenly I could save at will going forward - and also paste.

So my theory has changed to some component not initialising quickly, timing out, and blocking both pasting and saving much of the time. A real mystery, which is strongly tempting me back to 6.4.6

Is there any other info that I can get, or diagnostics/commands to run which might provide useful info?

Right at this exact moment, when I open new spreadsheets with old ones already open, they seem to be behaving... though if I reboot, they won't be behaving properly anymore.
Comment 6 V Stuart Foote 2020-09-25 13:37:04 UTC
(In reply to BikeHelmet from comment #5)

Unfortunately the InsideClipboard clips don't identify the application(s) with lock on the clipboard--the clipboard owner, which likely is not LibreOffice.

https://docs.microsoft.com/en-us/windows/win32/dataxchg/clipboard?redirectedfrom=MSDN
 
> 
> So my theory has changed to some component not initialising quickly, timing
> out, and blocking both pasting and saving much of the time. A real mystery,
> which is strongly tempting me back to 6.4.6
> 

Sure that is likely... but could also be a 3rd party app holding the Windows clipboard--locking out LibreOffice. 

> Is there any other info that I can get, or diagnostics/commands to run which
> might provide useful info?
> 
> Right at this exact moment, when I open new spreadsheets with old ones
> already open, they seem to be behaving... though if I reboot, they won't be
> behaving properly anymore.

So as in the see also bug 62196#c28 -- what else on your system could be intefering with LireOffices Windows clipboard interface to the LO Xclipboard core?

You mention "Ditto", had you eliminated that from the configuration?  To provide meaningful Steps to Reproduce, you really need to isolate the system to Windows - LibreOffice - and the "source" of the clipboard content (e.g. a specific web browser). Other apps/utils should be shutdown.
Comment 7 BikeHelmet 2020-10-05 09:50:30 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2020-10-06 03:45:12 UTC Comment hidden (obsolete)
Comment 9 BikeHelmet 2020-10-19 21:01:51 UTC
(In reply to BikeHelmet from comment #7)
> Yes, I eliminated Ditto.
> 
> I still have lots of background software running, though. Short of going
> into Safemode, I don't think I can disable it all?
> 
> I just observed the behaviour again - I copied some numbers from Gmail into
> the Calculator, multiplied them, then copied them and could not paste them
> into LibreOffice. I could paste them back into an email or to another
> calculator window. A minute or so later I could paste them into LibreOffice,
> no problem.
> 
> I have been trying to find out what could be locking it, but so far no luck.
> https://superuser.com/questions/770476/how-to-check-which-application-has-
> the-clipboard-hold
> 
> Are there any other tools that could help me track it down?

I have gone back to 6.4.6 which has much better pasting behaviour. Although pasting occasionally breaks, using the Reload option on a file solves it instantly.
Comment 10 QA Administrators 2020-10-20 04:20:31 UTC Comment hidden (obsolete)
Comment 11 Colin 2020-11-07 12:05:11 UTC
Version: 6.4.6.2 (x64)
Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; 
Locale: sv-SE (en_GB); UI-Language: en-GB
Calc: threaded

I have ascertained the following:-

Whereas Shft+Ctrl+V should normally permit some control over the paste criterea, utilising Shft +ALT +Ctrl +V whilst copying from a web-site - from which the pasting fails - facilitates the paste special but automatically forces "unformatted text", thereby producing a single column unformatted copy.
 
Some sites permit sorting of their data. If that data for copying is a single dimension array then the +ALT paste ignores any data sorting in the page and produces the original layout as a single column NOT row - even if the site data is presented as a row.

My own lack of technical expertise dictates that I must assume the site utilises characters between the data elements which are interpreted as Carriage Returns by CALC - or it is an inherent CALC characteristic.

Having a number of files which are updated numerous times throughout the day I have been able to concoct a nominal workaround; For those trying to paste a two dimensional array of data it is necessary to utilise the +ALT Paste V variation into a #scratch sheet. This produces a single column which is then re-mapped into the desired layout within that same sheet. The genuine worksheet can simply reference the re-mapped cells.

Visit the desired site > marquee select the desired data > Copy > Select the #scratch workshheet at the fixed starting cell > +ALT Paste Special

Initially creating the re-mapped array is an overhead but once it's done, the workflow is as simple as cut&paste.

An unforeseen advantage of this approach is that the calling cells never get their formatting "amended" by a "careless" paste special.
Comment 12 Colin 2020-11-07 12:11:48 UTC
Sorry, Forgot to mention FIREFOX
Comment 13 BikeHelmet 2020-11-10 06:29:54 UTC
(In reply to Colin from comment #11)
> Version: 6.4.6.2 (x64)
> Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
> CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; 
> Locale: sv-SE (en_GB); UI-Language: en-GB
> Calc: threaded
> 
> I have ascertained the following:-
> 
> Whereas Shft+Ctrl+V should normally permit some control over the paste
> criterea, utilising Shft +ALT +Ctrl +V whilst copying from a web-site - from
> which the pasting fails - facilitates the paste special but automatically
> forces "unformatted text", thereby producing a single column unformatted
> copy.
>  
> Some sites permit sorting of their data. If that data for copying is a
> single dimension array then the +ALT paste ignores any data sorting in the
> page and produces the original layout as a single column NOT row - even if
> the site data is presented as a row.
> 
> My own lack of technical expertise dictates that I must assume the site
> utilises characters between the data elements which are interpreted as
> Carriage Returns by CALC - or it is an inherent CALC characteristic.
> 
> Having a number of files which are updated numerous times throughout the day
> I have been able to concoct a nominal workaround; For those trying to paste
> a two dimensional array of data it is necessary to utilise the +ALT Paste V
> variation into a #scratch sheet. This produces a single column which is then
> re-mapped into the desired layout within that same sheet. The genuine
> worksheet can simply reference the re-mapped cells.
> 
> Visit the desired site > marquee select the desired data > Copy > Select the
> #scratch workshheet at the fixed starting cell > +ALT Paste Special
> 
> Initially creating the re-mapped array is an overhead but once it's done,
> the workflow is as simple as cut&paste.
> 
> An unforeseen advantage of this approach is that the calling cells never get
> their formatting "amended" by a "careless" paste special.

Thanks, Colin. That's a good and practical work-around for an odd bug. I'll use that if I jump back to v7 again and the regular paste still isn't fixed.
Comment 14 Timur 2020-11-10 07:22:56 UTC
This bug is Unconfirmed and without reproducible steps (cannot be a website, some text..) 
For 2 reporters here, please have in mind that LO has more open bugs on paste, so this one is of low if any value. 
What you may do and would help is to test daily master called 7.1+ from https://dev-builds.libreoffice.org/daily/master/current.html.
Because I noticed an improvement in 7.1+ for paste which is still not confirmed, until more people start using it.
Comment 15 Andrew 2020-12-10 10:14:08 UTC
I have this problem erratically from version 5 on our company.
If this ocasion present you can just copy from LibreOffice to clipboard and problem immediately disappear.
As written above, drag&drop works always.
Comment 16 Colin 2020-12-10 10:55:20 UTC
(In reply to Timur from comment #14)
> This bug is Unconfirmed and without reproducible steps (cannot be a website,
> some text..) 
> For 2 reporters here, please have in mind that LO has more open bugs on
> paste, so this one is of low if any value. 
> What you may do and would help is to test daily master called 7.1+ from
> https://dev-builds.libreoffice.org/daily/master/current.html.
> Because I noticed an improvement in 7.1+ for paste which is still not
> confirmed, until more people start using it.

Please could you elucidate.

How does one report a bug whose very definition is an inability to cut and paste from a website without defining the reproduction steps as "First access a website - here's a good example that regularly fails for me"?
Comment 17 Andrew 2020-12-11 11:01:48 UTC
Created attachment 168051 [details]
InsideClipboard clp+

I just got snapshot of clipboard that cause a problem. I copy one text from one application and this erratically cause a problem. I save snapshot of clipboard with "InsideClipboard" and try to load in again. Every time that I load this snapshot it cause different result.
Comment 18 Andrew 2020-12-11 11:06:48 UTC
Created attachment 168052 [details]
InsideClipboard clp-

I save another clipboard snapshot with "InsideClipboard" with the same content and try to upload it again. But this copy attempt was causing a problem on the first paste. Every time I upload this image, the result is different.
Comment 19 Gerald 2021-02-12 05:37:34 UTC
I have also this bug. Since i use LibO. 7.0.4 it got worse. With LibO 6.4 this behaviour was much better, but also a bug sometimes ( if you copy and paste often, you got the content before and not the actual content ).
Comment 20 jasonkres 2021-02-12 23:49:41 UTC
Comment 6 suspects this may be "3rd party app holding the Windows clipboard--locking out LibreOffice". I think that root cause is also causing bug 116983. 116983 is possibly a dupe but this bug seems to say that Ctrl+V doesn't work ("Nothing pasted") either whereas in 116983, toolbar and context menu paste is grayed out but Ctrl+V (usually) works. Note that Step 9 is a simple plain text paste from Notepad++/Notepad so the steps involving copying from websites in this bug may be superfluous, thus making it more similar to 116983 but for the Ctrl+V apparently not working part (if I understand correctly).

If further investigating the clipboard locking angle, please see bug 116983 comment 81 for technical info on clipboard lock problem. Key point is other apps ARE allowed to BRIEFLY lock the clipboard, because that is the only way to determine what is on the clipboard. LO needs to accommodate. Right now, LO doesn't accommodate ANY duration of lockout. When the clipboard changes, a bunch of apps may be concurrently notified to check the clipboard including LO, so good chance the LO attempts fails due to the concurrency.

This behavior is kind of undocumented for Windows OleGetClipboard API, but the exclusivity is documented in the underlying OpenClipboard API, and I think LO will need code change for clipboard functionality to work reliably on Windows.
Comment 21 Buovjaga 2021-03-05 16:59:36 UTC
Bug 116983 was fixed, so could everyone affected test with Win-x86_64@tb77-TDF https://dev-builds.libreoffice.org/daily/master/current.html
Comment 22 b. 2021-06-03 18:50:42 UTC
propose 'WFM' as it's most likely just a variant of the fixed 'clipboard blocked problem(s)',
Comment 23 Buovjaga 2021-06-04 06:28:05 UTC
Yep, no response in 3 months, so let's close
Comment 24 Colin 2021-06-04 06:41:14 UTC
(In reply to Buovjaga from comment #23)
> Yep, no response in 3 months, so let's close

Is it defined as fixed in later versions as it's still a complete "Dog's Dinner" in

Version: 7.0.6.2 (x64)
Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: sv-SE (en_GB); UI: en-GB
Calc: threaded

If "Works for me" is a euphemism for "We have no idea what is the solution so let's simply abandon it" then who am I to question your wisdom? Just another impacted user.

Yes, "Dog's Dinner" is the new euphemism for SNAFU
Comment 25 Buovjaga 2021-06-04 06:43:41 UTC
(In reply to Colin from comment #24)
> (In reply to Buovjaga from comment #23)
> > Yep, no response in 3 months, so let's close
> 
> Is it defined as fixed in later versions as it's still a complete "Dog's
> Dinner" in
> 
> Version: 7.0.6.2 (x64)
> Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
> CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL:
> win
> Locale: sv-SE (en_GB); UI: en-GB
> Calc: threaded

Yes, the fix is not in 7.0.6, but in 7.1.2 and later versions. You can see this in the Whiteboard field of bug 116983
Comment 26 Colin 2021-06-04 06:53:03 UTC
(In reply to Buovjaga from comment #25)
> (In reply to Colin from comment #24)
> > (In reply to Buovjaga from comment #23)
> > > Yep, no response in 3 months, so let's close
> > 
> > Is it defined as fixed in later versions as it's still a complete "Dog's
> > Dinner" in
> > 
> > Version: 7.0.6.2 (x64)
> > Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b
> > CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL:
> > win
> > Locale: sv-SE (en_GB); UI: en-GB
> > Calc: threaded
> 
> Yes, the fix is not in 7.0.6, but in 7.1.2 and later versions. You can see
> this in the Whiteboard field of bug 116983

My Bad - I was looking at the version for this bug report - 7.0.0.0.alpha0+ and assumed that as it was earlier(?) than my release then it had the potential for being an erroneous assessment.
Comment 27 BikeHelmet 2021-06-04 08:00:18 UTC
I'll upgrade to the latest version and report back in a week or two on whether it's fixed or is still problematic for me.
Comment 28 V Stuart Foote 2021-06-04 12:30:44 UTC
in place for 7.2.0 and 7.1.3 release by

https://gerrit.libreoffice.org/c/core/+/112044
https://gerrit.libreoffice.org/c/core/+/111825

and backports.
Comment 29 BikeHelmet 2021-06-05 09:43:53 UTC
Still broken in 7.1.3 and newer.

https://youtu.be/309DiYn5J0k

It seems to have gotten stuck with some contents to paste, and never updates it again from the clipboard. I confirmed the clipboard did not contain what was being pasted. (Only the longer correct link.) It's like LibreOffice cached old clipboard data and got stuck on it. Previously it got stuck on nothing. (Blank / empty paste.)
Comment 30 Colin 2021-06-05 09:58:07 UTC
(In reply to BikeHelmet from comment #29)
> Still broken in 7.1.3 and newer.
> 
> https://youtu.be/309DiYn5J0k
> 
> Previously it got stuck on
> nothing. (Blank / empty paste.)

In 7.0.6.2 - Which I acknowledge is an earlier version - I did notice that if an attempt to paste with a simple Ctrl+V appeared to have an empty clipboard but then the next action was a special paste Ctrl+Shft+V and the "paste special" window was simply abandoned, the clipboard contents would paste as anticipated with a subsequent Ctrl+V.

Just throwing it into the pot. It may trigger a "Eureka" moment for somebody more knowledgeable.
Comment 31 Mike Kaganski 2021-06-05 10:32:01 UTC
(In reply to BikeHelmet from comment #29)
> Still broken in 7.1.3 and newer.
> 
> https://youtu.be/309DiYn5J0k

Please always start your screencasts with Help->About. I need to see what version exactly is being shown.