Bug 40262 - Incorrect clipboard data of cells (problem to insert it into other programs)
Summary: Incorrect clipboard data of cells (problem to insert it into other programs)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.3.3 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Clipboard
  Show dependency treegraph
Reported: 2011-08-20 21:28 UTC by Andreas J Guelzow
Modified: 2021-10-30 18:21 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:
Regression By:

clipboard content (4.07 KB, application/octet-stream)
2011-08-20 21:28 UTC, Andreas J Guelzow

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas J Guelzow 2011-08-20 21:28:33 UTC
Created attachment 50416 [details]
clipboard content

new spreadsheet,
enter c3 in C3
enter c4 in C4
select C3:C4

LOCalc places an ODF file on the clipboard as target
application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"

That ODF file does not just contain a table with 2 cells but a table with 3 columns and 4 rows, misleading other programs into pasting a larger area (should they decide to use the ODF file).
Comment 1 Markus Mohrhard 2011-08-23 20:28:36 UTC
I don't think that this is a bug. That is our internal representation of a table, and I don't think that we copy an odf file to the clipboard. So all applications supporting x-openoffice-embed-source-xml need to respect our design of this format.
Comment 2 Andreas J Guelzow 2011-08-23 22:14:05 UTC
Well, if this indeed not supposed to be an ODF file, then you should 
(a) not include a file named "mimetype" with the content:
(b) not refer to the ODF namespaces at the beginning of the other files such as styles.xml:
<?xml version="1.0" encoding="UTF-8"?>
<office:document-styles xmlns:office="urn:oasis:names:tc:opendocument:xmlns:office:1.0" xmlns:style="urn:oasis:names:tc:opendocument:xmlns:style:1.0" xmlns:text="urn:oasis:names:tc:opendocument:xmlns:text:1.0" xmlns:table="urn:oasis:names:tc:opendocument:xmlns:table:1.0" xmlns:draw="urn:oasis:names:tc:opendocument:xmlns:drawing:1.0" xmlns:fo="urn:oasis:names:tc:opendocument:xmlns:xsl-fo-compatible:1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:meta="urn:oasis:names:tc:opendocument:xmlns:meta:1.0" xmlns:number="urn:oasis:names:tc:opendocument:xmlns:datastyle:1.0" xmlns:presentation="urn:oasis:names:tc:opendocument:xmlns:presentation:1.0" xmlns:svg="urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0" xmlns:chart="urn:oasis:names:tc:opendocument:xmlns:chart:1.0" xmlns:dr3d="urn:oasis:names:tc:opendocument:xmlns:dr3d:1.0" xmlns:math="http://www.w3.org/1998/Math/MathML" xmlns:form="urn:oasis:names:tc:opendocument:xmlns:form:1.0" xmlns:script="urn:oasis:names:tc:opendocument:xmlns:script:1.0" xmlns:ooo="http://openoffice.org/2004/office" xmlns:ooow="http://openoffice.org/2004/writer" xmlns:oooc="http://openoffice.org/2004/calc" xmlns:dom="http://www.w3.org/2001/xml-events" xmlns:rpt="http://openoffice.org/2005/report" xmlns:of="urn:oasis:names:tc:opendocument:xmlns:of:1.2" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:grddl="http://www.w3.org/2003/g/data-view#" xmlns:tableooo="http://openoffice.org/2009/table" xmlns:css3t="http://www.w3.org/TR/css3-text/" office:version="1.2" grddl:transformation="http://docs.oasis-open.org/office/1.2/xslt/odf2rdf.xsl">

It is also quite strange that the file would just give just two error messages when run through an ODF validator:

upload:///mem-dump/META-INF/manifest.xml[2,88]:Error:element "manifest:manifest" is missing "version" attribute
upload:///mem-dump:Info:Generator: null

where the first error message is quite common with LibreOffice generated ODF files.
Comment 3 orcmid 2011-08-23 23:01:16 UTC
I wonder if a look into Paste Special is called for.

I assume that there are actually multiple formats that can be obtained from the clip-board for the indicated copy.

I know that an embeddable file source is used, but the question is whether the selection is preserved across the copy-paste into a different document, and whether something other than the full table can be obtained. 

(I assume the copy paste into the same spreadsheet copies two cells as expected.)

The issue may be with the default behavior relative to what the target in the destination document is.

Sometimes, to preserve formulas, it is necessary to embed more table than is shown via the selection.  

It strikes me that there are several variables here and we perhaps need more cases to surface what the usability issue is.
Comment 4 Andreas J Guelzow 2011-08-23 23:50:18 UTC
Dennis, what do you mean with "whether something other than the full table can be obtained"? The ODF file that is exported as the 
application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source
target is not the whole table. In the example any _content_ of cell A1 is not exported. A1 in the exported file is empty.

Of course there are other targets but they carry only a subset of the information, ie. typically little of the formatting.

I also do not understand your comment "if a look into Paste Special is called for". I am talking about the targets that are exported to external x clipboard. You can usually run only one instance of LOCalc, so any information exported to the x-clipboard should be destined to an other application. 

I guess we will need to use the html target instead (which of course carries only little information).
Comment 5 Björn Michaelsen 2011-12-23 12:32:28 UTC Comment hidden (obsolete)
Comment 6 Andreas J Guelzow 2011-12-23 13:04:46 UTC Comment hidden (obsolete)
Comment 7 sasha.libreoffice 2012-02-01 07:00:10 UTC
@ Andreas
If it is not secret information, please, tell which program pastes clipboard incorrectly
Comment 8 Andreas J Guelzow 2012-02-01 08:30:08 UTC
@sasha, the problem is visible when pasting into Gnumeric. We (Gnumeric) could of course be using a different target but those don't seem to contain all formatting info or are not publicly documented. How does LibreOffice know which part of the table to use?
Comment 9 sasha.libreoffice 2012-02-01 21:12:31 UTC Comment hidden (obsolete)
Comment 10 Kohei Yoshida 2012-02-01 21:36:25 UTC

FYI, when pasting between libreoffice we don't go through the x-clipboard but use our own internal clipboard.
Comment 11 Kohei Yoshida 2012-02-01 21:38:30 UTC
Interestingly from gnumeric to libreoffice calc we seem to paste data as html...
Comment 12 Rainer Bielefeld Retired 2012-02-01 23:23:05 UTC
I did some tests with "LibreOffice 3.5.0 RC2 German UI/Locale [Build-ID: e371a95-bf68a13-5a1aa2b-d3c1ae9-b938258] on German WIN7 Home Premium (64bit) and others, several OOo versions, GNUMERIC 1.10.14, MS EXCEL Viewer and MS EXCEL (Starter) 2010)

a) I see the GNUMERIC effect: copy/paste due to report activates selection of a very big range including 2 rows above and 2 columns left of contents, as it seems more or less until right bottom end of GNUMERIC sheet. 
a1) No problem when copy/paste from MS EXCEL (Starter) 2010  to GUNUMERIC
a2) No problem when I copy/paste from LibO to MS EXCEL (Starter) 2010

b) This selection issue is a blemish, but a really bad thing is that a paste of selected 2 cells  range does not hit the expected target. Clicking on C3 in GNUMERIC to paste the contents will create a range as written above in 'a' and put the cell contents into E5:E6
b1) No problem when copy/paste from MS EXCEL (Starter) 2010 to GUNUMERIC
b2) No problem when I copy/paste from LibO to MS EXCEL (Starter) 2010

c) Another bad effect is that all GNUMERIC contents in range due to 'a' will be deleted (overwritten with empty cell)
c1) No problem when copy/paste from MS EXCEL (Starter) 2010  to GUNUMERIC
c2) No problem when I copy/paste from LibO to MS EXCEL (Starter) 2010

d) It's not only a LibO effect, same with copy/paste from OOo 1.1.4, OOo 3.1.1. to GNUMERIC

e) Copy / paste similar to report from GNUMERIC fails to OOo 3.1.1, LibO 3.5 RC2 with Error message (Translated: Unable to paste clipboard contents)
e2) Also impossible to paste to MS EXCEL (Starter) 2010

Currently I cant exclude that it's also a GNUMERIC problem, but I can't exclude that also LibO's compatibility is not optimum
Comment 13 Andreas J Guelzow 2012-02-01 23:44:33 UTC
LibreOffice provides various targets on the clipboard:

Clipboard target 0 is text/plain;charset=utf-8
Clipboard target 1 is text/plain;charset=UTF-8
Clipboard target 2 is UTF-8
Clipboard target 3 is UTF8_STRING
Clipboard target 4 is COMPOUND_TEXT
Clipboard target 5 is STRING
Clipboard target 6 is application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
Clipboard target 7 is application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="calc8";viewaspect="1";width="2259";height="451";posx="0";posy="0"
Clipboard target 8 is application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
Clipboard target 9 is application/x-openoffice-emf;windows_formatname="Image EMF"
Clipboard target 10 is application/x-openoffice-wmf;windows_formatname="Image WMF"
Clipboard target 11 is application/x-openoffice-bitmap;windows_formatname="Bitmap"
Clipboard target 12 is PIXMAP
Clipboard target 13 is image/bmp
Clipboard target 14 is text/html
Clipboard target 15 is application/x-openoffice-sylk;windows_formatname="Sylk"
Clipboard target 16 is application/x-openoffice-link;windows_formatname="Link"
Clipboard target 17 is application/x-openoffice-dif;windows_formatname="DIF"
Clipboard target 18 is text/richtext
Clipboard target 19 is application/x-openoffice-editengine;windows_formatname="EditEngineFormat"
Clipboard target 20 is MULTIPLE

Copy/paste from MS EXCEL (Starter) 2010  to GUNUMERIC does not use the 
application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" target. So any observation with respect to this transfer does not apply to the issue at hand.

Similarly it is unlikely that  copy/paste from LibO to MS EXCEL (Starter) 2010 uses that target.

Of course Gnumeric could easily switch to one of the other targets but it seems that they do not provide all the formatting information that is contained in the application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)" target. So switching to a different target would loose more formatting info when copy/paste.
Comment 14 Diane 2014-08-23 16:37:03 UTC
Comment on attachment 50416 [details]
clipboard content

copy/paste picks up previous clipboard content instead of currently selected cell(s)
Also happens in Writer - most recent prior text is copied and inserted instead of currently selcted word/text block
Comment 15 orcmid 2014-08-23 17:19:40 UTC
(In reply to comment #14)
> Comment on attachment 50416 [details]
> copy/paste picks up previous clipboard content instead of currently selected
> cell(s)
> Also happens in Writer - most recent prior text is copied and inserted
> instead of currently selcted word/text block

I have observed this on Windows across other applications.  I think this may be some sort of aberration related to how multiple copies (i.e., different selections, not just different clip-board format choices) can be on the clipboard at the same time in later versions of Windows and of Microsoft Office.  Or, for some reason, the second copy to the clipboard just doesn't "take." 

I believe this is a different problem than the subject of the current bug, however.
Comment 16 QA Administrators 2015-09-04 02:47:47 UTC Comment hidden (obsolete)
Comment 17 QA Administrators 2016-09-20 10:28:41 UTC Comment hidden (obsolete)
Comment 18 QA Administrators 2020-10-20 04:20:16 UTC
Dear Andreas J Guelzow,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team