https://bugs.documentfoundation.org/show_bug.cgi?id=144124
--- Comment #4 from Thomas Tempelmann <tempelm...@gmail.com> --- 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. -- You are receiving this mail because: You are the assignee for the bug.
