Apache OpenOffice (AOO) Bugzilla – Issue 117990
EditEngine-internal clipboard format doesn't work on Mac
Last modified: 2012-07-25 09:10:32 UTC
On MacOS only: Type some text into a Calc cell, select and copy some of the letters within the cell (edit mode in the cell), paste in the same cell again (still in edit mode). The pasted text has a wrong font size. When pressing Enter, the whole cell text gets a different font if the pasted text was not at the end of the cell. Apparently this (along with some other effects) is because normal RTF is pasted instead of EditEngine's internal format. It was introduced with a change for #163153# in CWS calc63, "mXClipboardContent.clear" in AquaClipboard::flushClipboard. The EditEngine always calls flushClipboard directly after copying (ImpEditView::CutCopy).
Created attachment 76495 [details] fix for transporting OOo types through system clipboard
The reason is that the mac clipboard implementation puts only data types it knows how to convert to/from system data types into the clipboard. That is not the case for off internal types like the edit engine format. Attached patch fixes this by pushing/pulling the binary data of internal types also. @nn: please review
Is the loop to release potential NSStrings really supposed to be in the constructor?
Created attachment 76497 [details] improved patch
No, that was just me being an idiot :-( Second patch should be better.
With the patch, I have seen a crash several times, and can't reproduce it in a normal 340m0. This may be coincidence, but perhaps you have an idea. 1. Open a Calc and a Writer document, type some text in Writer 2. Copy some words from the Writer document to the clipboard 3. Copy some cells from the Calc document to the clipboard Steps 2 and 3 may have to be repeated some times.
This seems to be rooted in the fact that now we have not only static NSStrings; when they get put into the type list reported to cocoa, the strings get released when that list is destroyed. With static strings that does not matter, retaining and releasing them supposedly does not do anything. With the new normal NSString objects however, that means a duplicate release when it comes to the destructor of the DataFlavorMapper. retaining the string before putting them into the respective NSArray fixes that problem. I also though whether we should only have one of these hash_maps since the set of mimetypes will not change much over time; however since mimetypes can have arguments (after the ';' character) and I know that OOo actually makes use of that sometimes (at least in the unix X11 clipboard), the set of mimetypes might indeed be variable and then one static map might grow too large. I am undecided whether this is really going to happen or we should get a static map after all. So I'll attach that fixes the retain count before inserting the string into the type array.
Created attachment 76503 [details] even more improved patch
Review done, this looks good to me.
Applied as rev 1338268, thanks Philipp.
set release blocker flag for 3.4.1
Asking HDU to merge the fix also to the branch for AOO 3.4.1 Thx in advance.
Also applied as 1344697 for AOO 3.4.1
Verify fixed on trunk r1354384 and AOO 3.4 branch r1351960 Close this bug
set target milestone AOO 3.4.1