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
Given that this particular clipboard format is *intended* to create links to the place in the document from where the data was copied, and its behavior is *designed* to create a bookmark in the original document upon paste, so that the place is addressable - how would a fix be possible? Reading from the format means for the program that some application indeed asks to create the link.
I understand now better the purpose if this behavior. The Mac's public clipboard is not meant to be used for such transactions that have side effects. Instead, other communications are better suited for this, such as AppleScript (which you are most probably not planning to add), IPC or even a specially named Pasteboard (based on your app's bundle ID). Are there even other Mac apps that know about this behavior and use it, ie. is this documented? If not, yet, maybe you could use a separate Pasteboard for this so that generic clipboard recorders do not run into trouble? I am happy to assist with this
I just found out that even Apple's own "Handoff" feature, which automatically synchronizes the clipboard between Macs and iOS devices, via iCloud, is affected by this issue: With Handoff enabled (I tested on macOS 10.13 High Sierra), selecting some text in Writer, then hitting Copy, a few seconds later the text becomes a bookmark. Without running any 3rd party app. This is a severe issue, because it means that when a Mac user using Handoff uses Writer and copied text in it, it'll become a bookmark every time unless the user quickly deselects the text again.
I have updated my ShowClipboards tool (now v2.3) to not fetch the data when it lists the types, but only fetch the data when you select its type. This means that if you want to reproduce the issue by following my initial instructions, you won't see the effect because ShowClipboards won't cause the issue automatically. To resolve this, and see the issue, either click on the "application/x-openoffice-link;…" type shown in either of ShowClipboard's windows, or use the older v2.2 from http://files.tempel.org/Various/ShowClipboards-2.2.zip
It’s quite bizarre that simply reading the shared pasteboard contents should cause the source document to become altered. (In reply to Mike Kaganski from comment #1) > Given that this particular clipboard format is *intended* to create links to > the place in the document from where the data was copied, and its behavior > is *designed* to create a bookmark in the original document upon paste, so > that the place is addressable - how would a fix be possible? By using an app-specific pasteboard instead of the shared one.
It might be needed in macOS case, to treat this clipboard format differently. Needs OS-specific knowledge. Patrick is the expert here. At least on Windows, it is *expected* that the *shared* clipboard contains the link entry, and so e.g. one may put a DDE link to Excel, which references a point in Writer's document. So at least there, this interchange format is not app-local.
I can investigate the hanging. But moving this to an app-internal clipboard would completely disable this feature. Presumably the feature was added because some users wanted it. Most likely, the LibreOffice UI would need to be changed to accomodate both groups of users. I am just a volunteer working on LibreOffice as a hobby so I do not feel comfortable messing with the LibreOffice UI. For that, you will need to lobby/petition TDF's UX design committee. Anyway, back to the hanging. I cannot reproduce the hanging in my local LibreOffice build on macOS Sonoma running on Mac Silicon. I have fixed several hanging and crashing bugs in LibreOffice's macOS accessibility code over the last year so does LibreOffice 7.6.4 or later still hang on your machine? If you can still reproduce a hang, is it possible for you to obtain and attach a sample of LibreOffice while it is hanging using the /Applications/Utilities/Activity Monitor application?
(In reply to Patrick Luby from comment #7) > moving this to an app-internal clipboard would completely disable this feature. > Presumably the feature was added because some users wanted it. Most likely, > the LibreOffice UI would need to be changed to accomodate both groups of users. Speaking about system-specific programming, I only know something about Windows; so please excuse if I speak nonsense here in macOS-specific issue. I can imagine, that the currently implemented behavior is just created uniformly on all OSes, with Windows-specific behavior being the main focus, without taking into account, that possibly this behavior (pasting DDE links to other applications) might make no sense on other OSes (?). It could make sense like "well, even if this format is not used on other OSes, it doesn't hurt; so the less system-specific code, the better". On all other OSes, it *might* be a reasonable assumption that only pasting DDE links from LibreOffice into LibreOffice itself might be useful, to create links between different LO documents. If so, then an app-internal clipboard would retain the main use case, so not disable it completely. All that makes sense only if pasting DDE links to applications other than LibreOffice itself doesn't make sense on macOS. And here, I lack any expertise.
> But moving this to an app-internal clipboard > would completely disable this feature. Just to be clear, by “app-specific pasteboard” I was referring to a system-provided pasteboard with a unique LO-specific identifier, not some proprietary construct. But I realize that, even then, it may not be simple to implement. An obvious alternative solution would be to introduce a dedicated command for copying DDE links. I’m going to go out on a limb and say that the vast majority of LO users don’t even know about DDE links, and for those that do, creating a link is not a frequent operation, particularly compared to just copying content. So, realistically, there is no need to prepare for link creation every time the user hits Cmd-C. Creating the link in the destination document currently requires invoking “Paste Special”. Why not turn this situation around and start by invoking a “Copy Link” action at the source? This approach would also be a boon for discoverability. Right now, I guess the only place in the UI that even suggests that links are a thing is in the “Paste Special” dialog. DDE linking can be useful, but I imagine almost no one knows about it. > All that makes sense only if pasting DDE links to applications other than > LibreOffice itself doesn't make sense on macOS. I’m not aware of any macOS app (except LO) that you could paste a DDE link into.
I agree with Kalle: - DDE links are simply unknown on macOS, i.e. there's no documentation on it, and clipboard behavior is expressly meant not to cause these side effects. However, Microsoft apps (Word, Excel) do show similar problematic behavior on macOS, i.e. when a clipboard recorder blindly saves all clipboard data and later restores the clipboard contents, the data is not pasted back correctly into Word or Excel, because the links included in the clipboard data have since been invalidated, and the MS apps don't like that (there's, sadly, no fallback code for such cases). Which means, all the clipboard recorders on macOS have to know about these special types of data in the clipboard and ignore those (and MS keep changing those every few years for our pleasure). - macOS provides alternative clipboards. Some have official names (e.g. the "Find" clipboard where apps put a search term into, sharable between apps) and the rest are private (by naming them with a random identifier, ideally a reverse domain name). The private ones are ignored by clipboard recorders but are still sharable. So, if there are other apps who'd like to make use of DDE features, including LO itself, it would be safer to use such a private clipboard for this purpose, while putting all "plain" (unlinked) data into the official clipboard. And then document this behavior. As a bonus, I'm maintaining the domain utis.cc where we document special types. We could add a reference to LO's behavior there (not that I think anyone will ever be interested). I believe that, by using an additional private (i.e. named) pasteboard, the Copy/Paste code in LO could be changed fairly locally, without needing changes to the UI, even. The change would be that, instead of reading/writing all data in the various "flavors" of the default pasteboard, those flavors that are DDE related would be put into the private clipboard instead. That way, LO will still be able to write and read back the DDE links, whereas other apps won't get confused by the DDE data when reading the default clipboard, not will they cause LO documents to get altered (unless that side effect has since been fixed somehow, as Patrick has suggested).
I wanted to add: I wonder if LO's DDE features can interact with Word, in either way. If that's possible, then that might indeed be useful, and then the current code where the DDE links get inserted into the default clipboard might be kept, but the UI should be changed to make this an explicit behavior but not the the default behavior. OTOH, if Word's own DDE(?) behavior (I have no idea how to use that, so I cannot test it) cannot be exchanged with LO's, then there's no need to keep the DDE feature in the default clipboard and it should instead be moved into a separate private pasteboard.
> I wanted to add: I wonder if LO’s DDE features can interact with Word, > in either way. They can’t. Linking between MSO and LO documents is not possible on Mac, neither with DDE nor OLE.
✋ macOS user here, unaware of DDE or OLE links. Never used them, never missed them. It would be amazing if LO just gave me the clipboard content without interfering with it. Clipboard has been wonky for as long as I have been using LO (over a decade now) and has exposed the weirdest behavior preventing effective work from getting done. Clipboard managers like Raycast, Launchbar or many others are very common on macOS. They all seems to run into similar trouble. Getting wrong contect from the clipboard while try ing to get work done is highly frustrating. If dropping DDE on macOS resolves this, here is my 💯 for doing that. If there are special edge-cases requiring DDE than that should be just that, a special option somethwhere (TM) for that edge-case and not the default.
My ha'penneth. Not a huge fan of DDE, and never seen it working properly on macOS, even with Word/Excel. As far as I'm concerned, as a user of LO on macOS, I see no need for it, but inevitably, someone might argue that DDE needs to be supported on macOS for LO due to cross-platform compatibility requirements, i.e. in a heterogeneous environment, if I produce a document on Windows with DDE links and then share them with someone on macOS, I might expect those DDE links to be respected and function (even if this has never really happened). I am also pretty sure that the whole DDE question was debated to death in a previous LO bug report *ages* ago, but can't be bothered to go and hunt that down right now.
(In reply to Alex Thurgood from comment #14) Note that DDE works cross-platform *inside LibreOffice*. You may create such links between two Calc documents, and they would work on Windows, Linux, or macOS. See e.g. https://ask.libreoffice.org/t/query-on-paste-special-of-a-dde-link-from-calc-cells-to-writer-endnotes/53733, which discusses some specific problem with DDE links, which "works fine" when not created in endnotes. Some specific problems (which need their Bugzilla issues, and a proper fix) is not the same as "this has never really happened". But the current situation with the shared clipboard is not related to the internal use of DDE, which is possible to have with internal clipboard (not even macOS-specific pasteboard with an unique ID, described in comment 9). Shared clipboard is only needed to enable *other* applications to use DDE links; and that *might* be totally impossible on systems other than Windows, where DDE is implemented on OS level. I could imagine, that on macOS and Linux, any application would be unable to know how to run a DDE server other than itself, or how to communicate with it. Then use of shared clipboard for DDE is totally unwarranted on these platforms. Anyway, "I don't need it" is absolutely not helping in issues like this.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3d9ee9375d28f0131949ee3c1f86f22dcea41d19 tdf#151679 Do not push FLAVOR_LINK to macOS general pasteboard 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 (27 December 2023) nightly master build: https://dev-builds.libreoffice.org/daily/master/current.html LibreOffice already has its own internal, private clipboard so all I needed to do was filter out the unwanted data flavor when declaring available types on the macOS system clipboard.
Verified in 24.8.0.0.alpha0+ (X86_64), build 40617d867346956588ac023511f31210107217f4. After copying text from Writer and inspecting the general pasteboard contents, an unwanted DDE link is no longer created in the document. The problematic content type `application/x-openoffice-link` no longer appears in the pasteboard. Accessing the two remaining special content types (`application/x-openoffice-embed-source-xml` and `application/x-openoffice-objectdescriptor-xml`) does not seem to trigger any side effects. Creating DDE links within LO (via Paste Special) continues to work normally. Thanks for tackling this!
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/7e4fd3c226d440d167a6581f82d8a83b628bcaa4 tdf#151679 Do not push FLAVOR_LINK to macOS general pasteboard 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/97f075ab95a592e9bd482031468b85e8bb7dc469 tdf#151679 Do not push FLAVOR_LINK to macOS general pasteboard 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.