Description: Selecting previous (not the latest) clipboard content via clipboard manager tool like LaunchBar (https://www.obdev.at/products/launchbar/index.html) pastes the newest clipboard entry instead of the one selected. This affects all LibreOffice components and is not 100% reproducible but happens frequently. Sometimes it also works as expected. Unsure what triggers the faulty behavior. Filing this specifically against LO on macOS as copy paste behavior differs per OS. Steps to Reproduce: Using LaunchBar as example clipboard manager tool, other clipboard tools may or may not have the same problem. LaunchBar is available as free trial https://www.obdev.at/products/launchbar/index.html 1. open LaunchBar > Preferences > Clipboard 2. set capacity to "1 day" and action to "Copy and Paste" 3. copy a few text snippets to fill clipboard history 4. start pasting via set shortcut Actual Results: Upon selecting an older entry actually the latest clipboard entry is pasted into LibreOffice component. Expected Results: Selected entry should be pasted instead. Reproducible: Sometimes User Profile Reset: No Additional Info: Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Mac OS X 11.5.2; UI render: default; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded Do not recall this has ever worked in the past.
I can confirm that something is wonky, and that LO is not compatible with Launchbar I copied some file names from Finder, those seemed to paste into LO fine I then copied two text snippets from LO, then the wonky behavior started No matter what I choose to paste now, it is the last item that I copied in LO Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 10; OS: Mac OS X 12.2; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I confirm this bug. I use Alfred's Clipboard history on macos. The bug occurs, if I copy an item (i. e. text) to clipboard from LO window. Then, no matter what i choose from Alfred Clipboard history, only the item copied to clipboard from LO is pasted. After I switch to another window and back to LO, everything works as expected. This bug is on LO 7.1.8, but it occured also on LO 7.3.0. Version: 7.1.8.1 / LibreOffice Community Build ID: e1f30c802c3269a1d052614453f260e49458c82c CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: sk-SK (sk.UTF-8); UI: sk-SK Calc: threaded
I see this bug frequently while using Alfred and LibreOffice. If I copy anything in LibreOffice Writer, I cannot paste anything from Alfred until I switch to a different app (not just another LibreOffice window), and switch back. Until I switch away, trying to use Alfred's clipboard (including Alfred's Snippets) only pastes whatever Libreoffice copied most recently. After switching away from Libreoffice and back, Alfred works as expected until I copy anything in Libreoffice. Interestingly, if I copy something in Libreoffice, then try to paste something from Alfred, Libreoffice's paste keeps pasting the same thing until I switch to another app. When I switch back to Libreoffice, Libreoffice's paste pastes the desired Alfred content. There's something different about how the clipboard is refreshed when returning to LibreOffice that isn't done when pasting after a copy.
Author of iClip here, which is another clipboard recorder. This is a known issue with both Office app and with LibreOffice. Both make the same "dangerous" assumptions: That the clipboard is not accessed by other app unless they become frontmost and Office/LO become deactivated. They also assume that when they find special "personal" types in the Clipboard, that they were put there just before from a Copy in the same program, and thus they can have references to internal objects (in memory) that are still valid. One of these assumptions is that if the user wants to paste something that was previously copied in the same app, then the clipboard must contain the data from the LAST Copy operation. These assumptions all break with a clipboard recorder, because the recorder will store the entire clipboard in a database and will put it later back into the clipboard, which can be at a time when the LO/Office app was even quit in between. In such cases, a Paste into the Office/LO app will contain all the personal types (for LO, that would be all those starting with "x-application/" in their name, and the app then assumes that this data in the clipboard must be from the most recent Copy in the app. Fixing this requires some internal changes, which, depending on the design (I don't know) could be quite complex. Basically, a Copy operation in LO would need to store self-contained descriptions of all involved objects (e.g. full image data of what's been copied, etc.) in a personal clipboard type, and mark it as "promised", so that the data doesn't have to be actually generated unless a process (such as the clipboard recorder) wants to fetch it (this is handled thru a callback). That way, as long as Copy & Paste happen only within LO, there's no performance panelty. But if a clipboard recorder wants to fetch it, it will incur more CPU usage, but that's the user's choice, and if he doesn't like that it slows down LO every time he copies something within, he can tell the recorder to not auto-record copied from that app, unless explicitly wanted (iClip can do that, not sure about others). If there are questions on how to implement this, I'm happy to assist. BTW, iClip implements a work-around for this issue by special-handling LO (and Office) cipboards by it not recording the app-specific personal types. That way, iClip only records the common types such as RTF and plain text, which then works in most cases. In fact, a few personal LO types are still recorded (which were found by trial-and-error), so that, for instance formulas from LO Calc can be copied and later re-pasted. But the special treatment is a mess and requires constant updates, and ideally LO should just use the Clipboard correctly so that such issues won't even arise in the first place.
BTW, I recently filed a related bug: 151679
@Thomas: you can add related bugs to the see also section. I did that for #151679 for you.
In order to trigger this bug some content from LibreOffice has to be copy pasted. Once that has happened all content from any clipboard manager will never be posted and always be replaced with the paste from LibreOffice. Prior to pasting something inside of LibreOffice the clipboard manager works as expected and various clipboard contents from the past can be pasted successfully.
(In reply to steve from comment #7) > In order to trigger this bug some content from LibreOffice has to be copy > pasted. > > Once that has happened all content from any clipboard manager will never be > posted and always be replaced with the paste from LibreOffice. > > Prior to pasting something inside of LibreOffice the clipboard manager works > as expected and various clipboard contents from the past can be pasted > successfully. My first guess is that LibreOffice is not handling any macOS "pasteboardChangedOwner:" callbacks. A quick grok of the vcl/osx code only contains no implementation of that selector. So, after a clipboard manager has fetched all of the data from the macOS system clipboard, it becomes the owner of the system clipboard but LibreOffice does not know that because it isn't listening for the "lost ownership" message. Since LibreOffice still wrongly thinks it is the system clipboard owner, when pasting within LibreOffice, LibreOffice bypasses the system clipboard and uses its own internal, private clipboard. I eliminated this "lost ownership" handling several year ago in NeoOffice. When I get some spare time, I will see if I can adapt that code to LibreOffice.
I can reproduce this with LaunchBar. What is interesting is that LibreOffice never receives a "lost ownership" notification when I select an older entry in LaunchBar's history list. But if I quit LaunchBar, then LibreOffice properly receives a "lost ownership" notification. Note: the following debug patch that I used in my local LibreOffice build: diff --git a/vcl/osx/clipboard.cxx b/vcl/osx/clipboard.cxx index 5d925b3b1954..c37453d0d073 100644 --- a/vcl/osx/clipboard.cxx +++ b/vcl/osx/clipboard.cxx @@ -46,6 +46,11 @@ using namespace css; pAquaClipboard->provideDataForType(sender, type); } +-(void)pasteboardChangedOwner:(NSPasteboard *)sender +{ + fprintf(stderr, "Lost ownership!\n"); +} + -(void)applicationDidBecomeActive:(NSNotification*)aNotification { if( pAquaClipboard ) diff --git a/vcl/osx/clipboard.hxx b/vcl/osx/clipboard.hxx index 6213ce692106..360a83cd81d0 100644 --- a/vcl/osx/clipboard.hxx +++ b/vcl/osx/clipboard.hxx @@ -55,6 +55,8 @@ class AquaClipboard; // Promise resolver function - (void)pasteboard:(NSPasteboard*)sender provideDataForType:(const NSString *)type; +-(void)pasteboardChangedOwner:(NSPasteboard *)sender; + -(void)applicationDidBecomeActive:(NSNotification*)aNotification; -(void)disposing;
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cefd36db5f9389dd6f7e605eca6711762a784966 tdf#144124 Detect if ownership has been lost It will be available in 24.8.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.
I have committed my fix for this bug and it will be included in tomorrow's (28 December 2023) nightly master build: https://dev-builds.libreoffice.org/daily/master/current.html I found where LibreOffice needs to check if LibreOffice has lost ownership of the macOS system clipboard.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/226e23d6a26bb3710712e9a865c6b222cd3db76f tdf#144124 Detect if ownership has been lost It will be available in 7.6.5. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/0e014306349e51b187322bc98b5e23644d017b85 tdf#144124 Detect if ownership has been lost It will be available in 24.2.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.
verified in Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0f6f5048d223731aa52b768a77244d0208711391 CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Raster; VCL: osx Locale: de-DE (en_DE.UTF-8); UI: en-US Calc: threaded This bug has been in LO forever and was easily one of the most annoying ones. When I was trying to get work done with LO there was frequent swearing because the clipboard could not be utilized. Family and neighbors send their thanks along with my personal THANK YOU.