Description: When I try to copy number from browser in libre Pastes copied cell Steps to Reproduce: 1.Copy cell with text 2.Copy other text from othr place 3.Paste in other cell Actual Results: Cell have text "amber tresses" and when I want to paste "866382" it puts "amber tresses" Expected Results: Expected to put "866382" from notepad not "amber tresses" from neighboring cell Reproducible: Sometimes User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: ru Module: SpreadsheetDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: yes Version: 7.3.2.2 (x64) / LibreOffice Community Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Calc: CL
Created attachment 179637 [details] Reproducing a bug with put wrong data from clipboard
(In reply to zeka10000.z1 from comment #0) > Reproducible: Sometimes Please try to find reproducible steps.
Confirmed in https://bugs.documentfoundation.org/show_bug.cgi?id=62196#c141 with: ----------------- c) Until now I don't know a way how to make the problem 100%reproducible d) Problem is not related to activated WIN10 feature "clipboard history"
Video attachment 179637 [details] makes a logical omission. When data is cut from Notepad++, clipboard is not shown, so we really can't say if bug is LO or N++. I'm using LO and N++ together and I'm seeing this a lot lately in Windows 7. So please try to reproduce without N++, confirming the bug in Clipboard.
*** Bug 151984 has been marked as a duplicate of this bug. ***
Mike, copying you in as this could be a follow-up from: - https://gerrit.libreoffice.org/c/core/+/112044 - https://gerrit.libreoffice.org/c/core/+/111825 According to this comment: https://bugs.documentfoundation.org/show_bug.cgi?id=136762#c29 Would be great if someone who can reproduce the issue can test if it indeed started from versions 7.1.3 or 7.2.0. (And just test with older versions anyway to see if this issue is a regression.) Rainer reproduced in 7.2 according to comment https://bugs.documentfoundation.org/show_bug.cgi?id=62196#c142
*** Bug 152927 has been marked as a duplicate of this bug. ***
(In reply to Stéphane Guillou (stragu) from comment #6) > Mike, copying you in as this could be a follow-up from: > - https://gerrit.libreoffice.org/c/core/+/112044 > - https://gerrit.libreoffice.org/c/core/+/111825 > According to this comment: > https://bugs.documentfoundation.org/show_bug.cgi?id=136762#c29 > > Would be great if someone who can reproduce the issue can test if it indeed > started from versions 7.1.3 or 7.2.0. (And just test with older versions > anyway to see if this issue is a regression.) > > Rainer reproduced in 7.2 according to comment > https://bugs.documentfoundation.org/show_bug.cgi?id=62196#c142 Hello Stéphane, I have just tested it with portable Version of: Version: 7.2.7.2 (x86) / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL Still the same problem within LO with the Clipboard. The failure is in ALL Apps from LO, not only calc Tested with Draw, Impress, Writer and Calc
Adjusting component to LibreOffice since all apps are affected as per https://bugs.documentfoundation.org/show_bug.cgi?id=148647#c8 Should OS be switched to all since I have been seeing this on macOS as well in recent main builds. What about priority? https://bugs.documentfoundation.org/show_bug.cgi?id=62196 had highest and this has medium but from what I can tell it is the same problem. Sadly no trivial repro steps on macOS. In my test just now pasting behaved as expected but I am aware this frequently is a problem and it is fairly infuriating, since LibreOffice will refuse to paste the correct content.
(In reply to steve from comment #9) > Should OS be switched to all since I have been seeing this on macOS as well > in recent main builds. No. *Until proven otherwise*, all such problems (i.e., related directly to OS-specific features) must be considered OS-specific. It would really be great if it turned out to be OS-independent, because it would bean it's possible to fix it for all of them at once. Note that this is only "same problem" when you consider the manifestation / priority. But indeed, technically, this is a different problem, that needs a separate fix.
Doing some more tests I now am pretty sure that this problem is (at least also) caused by interaction with other running Applications. Steps how to reproduce with Installation of Version: 7.5.0.1 (X86_64) Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: default; VCL: win – Locale: de-DE (de_DE); UI: de-DE Calc: threaded | Elementary (SVG) Theme | Normal UserProfile 0. Install "MP3Studio YouTube Downloader" from https://mp3.studio/ 1. Launch LibO with empty new Writer document 2. Open existing writer Document 3. Open a Web Page in (SeaMonkey) rowser 4. Copy single word from existing writer Document (<cntrl+c>) → Paste to new Writer document (paste as plain text) 5. Copy single word from Web Page to new writer doc. (<cntrl+c> ... <ctrl+v>) 6. Redo (4) ... (5) several times, always copying a new word » always will work fine 7. Launch "MP3Studio YouTube Downloader" 8. Redo (4) ... (5) » expected: (5) will work fine actual: Clipboard contents from (4) pasted. 😥 Additional info: a) "MP3Studio YouTube Downloader" does some background actions copying youtube page URLs from Browser to "MP3Studio YouTube Downloader" b) I passed test (1) ...(8) several times with different web pages and different LibO source writer documents. Always broke after Step (7)
*** Bug 153415 has been marked as a duplicate of this bug. ***
(In reply to Rainer Bielefeld Retired from comment #11) > Doing some more tests I now am pretty sure that this problem is (at least > also) caused by interaction with other running Applications. Thanks Rainer, this description is consistent with duplicate bug 153415 comment 5, with the app Textbausteine Plus.
*** Bug 154346 has been marked as a duplicate of this bug. ***
*** Bug 154520 has been marked as a duplicate of this bug. ***
Likely the same issue as in earlier bug 101257.
*** Bug 156862 has been marked as a duplicate of this bug. ***
Upping Priority from Medium to High, seeing 6 duplicates with potentially more in See Also.
I've just hit this too. Writer Rel 7.6.5.2 64bit Windows 11.
Also seeing this in Libre Writer Version: 7.6.6.3 (X86_64) / LibreOffice Community Build ID: d97b2716a9a4a2ce1391dee1765565ea469b0ae7 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: CL threaded If you enable clipboard history in Windows 10 (PC settings->System->Clipboard->Clipboard History->On) You can press Windows Key + V and it will show the what you have copied in to the clipboard from another application. But Pressing CTRL + V in Libre Writer it will paste the last thing you copied in Libre Writer not what is in the clipboard, it seems to be ignoring what is actually in the OS clipboard, preferring it's own clipboard. It seems as a work around with clipboard history enabled, if you Press Windows Key + V and then click on the clipboard item in the window that Windows pops up, it pastes the right content in to Libre Writer
I have had this issue since OpenOffice, It is easy to reproduce. Open a document (Writer/Calc) 1) Copy - paste something from outside LO (works fine) 2) Copy - paste something from inside LO (works fine) 3) Copy - paste something from outside LO (does not work, it will paste the data from step 2. This happens consistently. The workaround is clearing the windows clipboard. This seems to reset the internal LO clipboard as well. see also: https://ask.libreoffice.org/t/why-cant-lo-paste-text-from-other-sources/87109 Current setup: Win 11 Home Build 22631 LibreOffice: 7.5.9.2 cdeefe45c17511d326101eed8008ac4092f278a9
*** Bug 136762 has been marked as a duplicate of this bug. ***
In https://ask.libreoffice.org/t/is-there-a-way-to-get-libreoffice-to-paste-text-in-windows/104986, TeamViewer was reported as affecting/causing this problem. Could you please check if this is related to this case, or not? Thanks.
(In reply to Mike Kaganski from comment #24) > In > https://ask.libreoffice.org/t/is-there-a-way-to-get-libreoffice-to-paste- > text-in-windows/104986, TeamViewer was reported as affecting/causing this > problem. Could you please check if this is related to this case, or not? > Thanks. Well, I encountered that just today. I was remotely working on a computer and needed to copy some numbers across. They won't paste directly into LibreOffice. I need to dump them into Metapad, Notepad++, a web browser text box, Wordpad, Word, an email program like Thunderbird, etc, then re-copy from there to paste into LibreOffice. Basically, any program other than LibreOffice that can work with the data type. At this point I have just gotten used to incorporating more copy+paste steps. I still occasionally need to tell LibreOffice to Reload the open document, to get the ability to Copy+Paste anything at all.
*** Bug 161856 has been marked as a duplicate of this bug. ***
I've encountered this problem when a very old unused version of AutoHotkey was installed on my computer. It was not running. Once I removed installed a newer version of AutoHotkey the problem went away. So it sounds like one way we can encounter the problem is due to interference from outside applications but why is it only Libre that is encountering the problem? Also, we've encountered problems in Libre when Vulkan Libraries were installed (Win10). These were installed by Microsoft during updates on Lenovo machines.
(In reply to Dan K from comment #27) > I've encountered this problem when a very old unused version of AutoHotkey > was installed on my computer. It was not running. Once I removed installed > a newer version of AutoHotkey the problem went away. > > So it sounds like one way we can encounter the problem is due to > interference from outside applications but why is it only Libre that is > encountering the problem? > > Also, we've encountered problems in Libre when Vulkan Libraries were > installed (Win10). These were installed by Microsoft during updates on > Lenovo machines. Note: Vulkan caused display problems not clipboard problems.
Since my report 161856 was considered a duplicate, I will paste my description from that report, because the problem of 100% repeatability is mentioned many times in this thread. In my description, I provided a recipe for 100% repeatability of the error: Description: When copying individual cells using the clipboard (Ctrl+C > Ctrl+V), everything works as it should. However, after selecting a larger number of cells and pasting them, Calc does not accept new text data copied using Ctrl+C, for example from Windows Notepad. It still remembers the last multi-cell data copied from Calc. In such a situation, only restarting Calc helps. Steps to Reproduce: 1. Copy several Calc cells with Ctrl+C 2. Paste them elsewhere in the same Calc sheet with Ctrl+V 3. Copy any text from Windows Notepad via Ctrl+C 4. Paste the data copied from Notepad into the same Calc sheet using Ctrl+V. Calc will instead paste the data copied in step 1 Actual Results: Calc only accepts new data copied from Calc Expected Results: Calc should also accept new data copied from other applications (e.g. Windows Notepad)
*** Bug 162029 has been marked as a duplicate of this bug. ***
https://gerrit.libreoffice.org/c/core/+/170459
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2e0664015255ffc0f76a11a9cb254564b34de496 tdf#148647: make sure to update own content on Win clipboard change It will be available in 25.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.
The just-merged change is a blind fix. I ask people who see the problem consistently, to test the daily builds that hopefully will be available tomorrow. I appreciate the feedback, if this seems improved / resolved for you, or not, using the build with the change. This is a Windows-only change; as mentioned elsewhere, these OS-integration bugs like clipboard problems are OS-specific, just as their fixes, even if similar problems manifest on different operating systems.
*** Bug 162039 has been marked as a duplicate of this bug. ***
(In reply to Rainer Bielefeld Retired from comment #11) > Doing some more tests I now am pretty sure that this problem is (at least > also) caused by interaction with other running Applications. I could reproduce with your steps in 7.1.0.3 and 24.2.4.2 on Windows 11 (note that it is also reproduced when the MP3 Studio window is closed but the app is still running in the background - it needs to be exited from the task bar's "hidden icons"). Thanks for looking into it, Mike, I can test in same conditions when the build is available.
When LibreOffice Calc & Writer exhibit this "bug", I've still successfully pasted the clipboard into Notepad, Sublime Text, Vivaldi address bar, Visual Studio text editor. FWIW I have the windows-key+V Clipboard history app disabled.
(In reply to Stéphane Guillou (stragu) from comment #35) > (In reply to Rainer Bielefeld Retired from comment #11) > > Doing some more tests I now am pretty sure that this problem is (at least > > also) caused by interaction with other running Applications. > I could reproduce with your steps in 7.1.0.3 and 24.2.4.2 on Windows 11 Pacepalm. I see now, that this had been here since Feb 2023; and even put into the bug's title; yet, I missed this all this time. I indeed repro with the steps, too. (In reply to Stéphane Guillou (stragu) from comment #6) > Would be great if someone who can reproduce the issue can test if it indeed > started from versions 7.1.3 or 7.2.0. Heh, for the record: I also reproduce with OOo 2.2.0 (2006). And I don't reproduce with master after the fix. So let me close it. Unless you see steps from comment 11 failing for you, please file *anything* looking similar after the said fix as new bugs. Indeed, if steps from comment 11 fail for you in current master (or, when the backport is finished, in 24.8), please feel free to reopen this one. If these steps fail in a future version (after 25.2), please file it as a new bug, and put this one to its See Also. Thanks.
For devs, if similar problems appear on other platforms: Check if there is an assumption that the ref-counted clipboard data object created from own data is destroyed when something new is copied to clipboard. This might not be true; external programs may have bugs (I have debugged why "MP3Studio YouTube Downloader" causes this, and indeed, it actively uses clipboard, but fails to release opened resources after it read them, keeping the data object in LibreOffice alive - so definitely a bug in the external program, which we should be ready for); and there may be legitimate cases for this, too. XClipboardOwner::lostOwnership [1] mechanism may be relevant when debugging this. [1] https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1datatransfer_1_1clipboard_1_1XClipboardOwner.html#a02a04014b37982364ae35a1c2c0618da
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/b9d32aa128ca1c8096a43c8d564a38330f1fc85c tdf#148647: make sure to update own content on Win clipboard change It will be available in 24.8.0.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.
*** Bug 162144 has been marked as a duplicate of this bug. ***