Issue 117990 - EditEngine-internal clipboard format doesn't work on Mac
Summary: EditEngine-internal clipboard format doesn't work on Mac
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 3.4 Beta
Hardware: Mac Mac OS X 10
: P3 Normal (vote)
Target Milestone: 3.4.1
QA Contact: issues@gsl
Depends on:
Reported: 2011-05-09 17:45 UTC by niklas.nebel
Modified: 2012-07-25 09:10 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 3.4.1_release_blocker+

fix for transporting OOo types through system clipboard (3.12 KB, patch)
2011-05-10 12:18 UTC, philipp.lohmann
no flags Details | Diff
improved patch (3.25 KB, patch)
2011-05-10 14:15 UTC, philipp.lohmann
no flags Details | Diff
even more improved patch (3.41 KB, patch)
2011-05-11 06:49 UTC, philipp.lohmann
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description niklas.nebel 2011-05-09 17:45:04 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).
Comment 1 philipp.lohmann 2011-05-10 12:18:59 UTC
Created attachment 76495 [details]
fix for transporting OOo types through system clipboard
Comment 2 philipp.lohmann 2011-05-10 12:21:09 UTC
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
Comment 3 niklas.nebel 2011-05-10 14:07:54 UTC
Is the loop to release potential NSStrings really supposed to be in the constructor?
Comment 4 philipp.lohmann 2011-05-10 14:15:43 UTC
Created attachment 76497 [details]
improved patch
Comment 5 philipp.lohmann 2011-05-10 14:16:26 UTC
No, that was just me being an idiot :-( Second patch should be better.
Comment 6 niklas.nebel 2011-05-10 22:33:34 UTC
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.
Comment 7 philipp.lohmann 2011-05-11 06:48:11 UTC
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.
Comment 8 philipp.lohmann 2011-05-11 06:49:24 UTC
Created attachment 76503 [details]
even more improved patch
Comment 9 niklas.nebel 2011-05-11 09:13:53 UTC
Review done, this looks good to me.
Comment 10 2012-05-14 16:11:55 UTC
Applied as rev 1338268, thanks Philipp.
Comment 11 jsc 2012-05-30 14:01:53 UTC
set release blocker flag for 3.4.1
Comment 12 Oliver-Rainer Wittmann 2012-05-30 14:03:21 UTC
Asking HDU to merge the fix also to the branch for AOO 3.4.1
Thx in advance.
Comment 13 2012-05-31 13:00:02 UTC
Also applied as 1344697 for AOO 3.4.1
Comment 14 Terry Yang 2012-06-28 06:29:10 UTC
Verify fixed on trunk r1354384 and AOO 3.4 branch r1351960
Close this bug
Comment 15 jsc 2012-07-25 09:10:32 UTC
set target milestone AOO 3.4.1