Bug 140813

Currently LibreOffice uses a dedicated thread to respond to clipboard change notifications (see CMtaOleClipboard in vcl/win/dtrans/MtaOleClipb.cxx), which obtains an IDataObject (using OleGetClipboard) for the updated clipboard data, and stores it for possible further use. The object is wrapped into an appartment-neutral object in CWinClipboard::getContents (vcl/win/dtrans/WinClipboard.cxx). This object is later queried for available formats when deciding if Paste should be enabled, and which paste options to provide. Often, this is the only information needed, because not every data in clipboard ends up in LibreOffice.

This is (a) rather expensive (obtaining a COM object, creating an appartment-neutral wrapper over it, having to properly release it at the next clipboard update - for each clipboard event, regardless if we will use the data or not), and (b) prone to errors (see e.g. tdf#136175; also there are hangs sometimes in unit testing, caused by deadlocking of released COM object waiting for a thread that is waiting for its release).

Since Windows Vista, there's GetUpdatedClipboardFormats function [1] created to list available formats in the system clipboard without opening it, and so without race conditions [2] [3]. We could possibly reimplement the thread to only get the list of available formats using this function, and only obtain the COM object when actually pasting something. That would require that the XTransferable returned from CWinClipboard::getContents would be able to ask for the IDataObject only when needed.

[1] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getupdatedclipboardformats
[2] https://techcommunity.microsoft.com/t5/microsoft-security-and/why-does-my-shared-clipboard-not-work-part-2/ba-p/246465
[3] https://support.citrix.com/article/CTX216506