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.
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.?
(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.
Created attachment 165828 [details] InsideClipboard - Contents Example
Created attachment 165829 [details] InsideClipboard - Contents Example
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.
(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.
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?
[Automated Action] NeedInfo-To-Unconfirmed
(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.
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.
Sorry, Forgot to mention FIREFOX
(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.
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.
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.
(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"?
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.
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.
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 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.
Bug 116983 was fixed, so could everyone affected test with Win-x86_64@tb77-TDF https://dev-builds.libreoffice.org/daily/master/current.html
propose 'WFM' as it's most likely just a variant of the fixed 'clipboard blocked problem(s)',
Yep, no response in 3 months, so let's close
(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
(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
(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.
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.
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.
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.)
(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.
(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.
(In reply to BikeHelmet from comment #29) > 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.) This new(?) issue is described in bug 148647. Given the number of comments, and the change in symptoms, let's keep this report closed and follow up in that one. If it is indeed a regression from the two commits referenced here, we can mark bug 148647 as such. Thanks everyone.
*** This bug has been marked as a duplicate of bug 148647 ***