https://bugs.documentfoundation.org/show_bug.cgi?id=151679
Bug ID: 151679
Summary: Clipboard contents on Mac cause trouble with clipboard
recorders
Product: LibreOffice
Version: 7.4.2.3 release
Hardware: All
OS: macOS (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: framework
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: tempelm...@gmail.com
Description:
When selecting and copying text in Writer, then having another program read the
entire clipboard (which is typical for Clipboard History recorders), the
clipboard type `application/x-openoffice-link;windows_formatname="Link"`will
cause several issues, including modification of the document and possibly a
program freeze.
Steps to Reproduce:
Get a tool that can show the clipboard contents, such as my own
"ShowClipboards", see http://www.tempel.org/ShowClipboards
Then open a plain text file in LO, select some text, hit Cmd-C. Now the
ShowClipboards windows detect the change of the clipboard and attempts to read
the data of all types (or it'll occasionally freeze).
Actual Results:
Once ShowClipboards has updated its windows with the clipboard contents, the
selected text in LO has become a bookmark (e.g. it gets faint brackets around
the text) and the just-opened text is marked as dirty.
Expected Results:
The document should not get dirtied, no bookmark should be made out of the
selection, and it should never lead to a program freeze.
Reproducible: Always
User Profile Reset: No
Additional Info:
Analysis:
There are several programs on the Mac that record the pasteboard whenever it
changes.
Examples are: iClip (mine), Keyboard Maestro, Alfred, and more.
Some of these only fetch text types, while others (including iClip and KM) try
to fetch and store all types for later Paste back into the same or another app.
While this works generally very well with any native Mac app, both MS Office
and LibreOffice cause a lot of problems, because both make assumptions that the
clipboard can't be read by another process unless the app gets deactivated.
iClip works around this with several methods that work in most times.
However, this bug report is about a more severe issue with LibreOffice alone:
LO Writer writes a type named:
application/x-openoffice-link;windows_formatname="Link"
The problem with this is that when, even after LO gets deactivated (put into
background), reading the data for this type will cause several effects:
- The document becomes dirty if it wasn't before.
- The selected text (that was previously copied) gets turned into a bookmark.
- When doing this with LO still frontmost, it can freeze both LO and the app
that attempts to read the data of this type from the Pasteboard.
Obviously, reading this type's data from the clipboard has a nasty side effect.
This is a severe issue and I'd ask that you fix this on your end, please. I
have implemented a work-around in iClip to not ever fetch this particular type,
but the fact that this even happens, is a design flaw and should be corrected
on your end.
Also, in general, the type names in a Mac clipboard are not supposed to change
dynamically, as it happens with your object-desc:
application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object
Descriptor
(XML)";classname="8BC6B165-B1B2-4EDD-aa47-dae2ee689dd6";typename="LibreOffice
7.4 Text
Document";displayname="file:///Users/tempi/Desktop/notes.txt";viewaspect="1";width="17000";height="3000";posx="0";posy="0"
That dynamic information (such as the file path) is supposed to go into the
data, not the type name. I don't expect you to change that, but please be aware
that LO is not a good Mac citizen in this regard, either.
Regards
Thomas Tempelmann
--
You are receiving this mail because:
You are the assignee for the bug.
