Created attachment 129697 [details]
Example spreadsheet

This is definitely a regression, it used to work just fine in the past.
(copy/paste is a rather key feature after all)

Hi Michale,

(In reply to Michal Svec from comment #0)
> Description:
> How to reproduce:
> - goto A2
> - Ctrl+C
> - goto B2
> - Ctrl+V
> -> "B1+1" is pasted (so far so good)

I see that too.

> - Ctrl+V (again)
> -> "1" is pasted (this is broken)

but I don't see that. B2 still has "=B1+1"
So sorry, I cannot reproduce.

On Version: 5.4.0.0.alpha0+
Build ID: b7c55b662810ee3bf82d134ff1ff9a96bfee4046
CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-12-15_01:12:52
Locale: nl-NL (nl_NL.UTF-8); Calc: group

Nor on Versie: 5.2.4.1 
Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22
CPU Threads: 4; Versie besturingssysteem:Linux 4.8; UI Render: standaard; VCL: gtk2; 
Locale: nl-NL (nl_NL.UTF-8); Calc: group

And works fine with:
Version: 5.2.4.1 (x64)
Build ID: 9b50003582f07ac674d6451e411e9b77cccd2b22
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
Locale: es-ES (es_ES); Calc: group

Interesting, it works fine on my nb, but on my workstation it's
reliably broken. Both have the same LO version, 5.2.4.1-2.1.x86_64

I will investigate the differences on Monday.

(In reply to Aron Budea from comment #6)
> Could be something GTK3-related?

Nope, tried it.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: db9aec4520766c87a09d4cb0238ed06ebaeaaeeb
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 18th 2016

So I identified the condition: when using KDE plasma "Clipboard contents"
settings and the setting "Synchronize contents of the clipboard and the
selection" is ON then the behavior is like the described. If I turn it
OFF then it seems to work fine.

Now, is that then a bug in LO or KDE?

(In reply to Cor Nouws from comment #9)

> > Now, is that then a bug in LO or KDE?
> 
> I'm not familiar with that KDE clipboard tool.
> Isn't the behavior what is described?

Certainly not (unless I am missing something). It should not change the
contents of the clipboard without a reason.

It looks like that either:
 a) Something (LO?) changes the contents of a clipboard after the first Paste
 b) Or the Plasma tool is broken and messes up the clipboard contents

Ok, I repro with the Clipboard setting (right-click the clipboard icon in task tray, settings, tick the box for synchronize..). Note that this setting is not ON by default, so lowering severity.

It might be a KDE problem.. I should perhaps poke the Plasma devs. Setting to NEW for now.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
Build ID: 6c2b8cb5b136b63b3ea295528b845d37b5dd9000
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on December 28th 2016

Please retest. I don't have KDE.

Still repro.

Arch Linux 64-bit
Version: 6.3.0.0.alpha0+
Build ID: 038e4b3b1e10d072b432cb06234521ae9a262a70
CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: kde5; 
Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US
Calc: threaded
Built on 12 May 2019

Since I'm currently reworking the Qt5 clipboard stuff to fix bug 122239 (testers wanted: https://gerrit.libreoffice.org/#/c/73288/), I have all the debugging set up, so here is what is happening (all lines starting with debug: are from LO):

m0 = clipboard (Ctr+C / Ctrl+V)
m1 = selection (what you can insert with the middle button)

If you want to "watch" clipboard changes do: watch -n 1 "xclip -selection clipboard -out; echo; xclip -selection primary -out"

Ctr+C
debug:11537:11537: setContents m0 c1 o1
=> we set the contents of the clipboard (m0) with stuff (c1) we own (o1)

debug:11537:11537: handleChanged m0 qo1
=> we get the information that the content of the clipboard (m0) has change and Qt knows we own it (qo1)

=> the clipboard has a lot of (potential) stuff in it, for a single cell:
debug:11537:11537:   application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
debug:11537:11537:   application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)";classname="47BBB4CB-CE4C-4E80-a591-42d9ae74950f";typename="LibreOffice 6.4 Tabellendokument";displayname="file:///tmp/bug.ods";viewaspect="1";width="2258";height="453";posx="0";posy="0"
debug:11537:11537:   application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
debug:11537:11537:   application/x-openoffice-emf;windows_formatname="Image EMF"
debug:11537:11537:   application/x-openoffice-wmf;windows_formatname="Image WMF"
debug:11537:11537:   image/png
debug:11537:11537:   application/x-openoffice-bitmap;windows_formatname="Bitmap"
debug:11537:11537:   image/bmp
debug:11537:11537:   text/html
debug:11537:11537:   application/x-openoffice-sylk;windows_formatname="Sylk"
debug:11537:11537:   application/x-openoffice-link;windows_formatname="Link"
debug:11537:11537:   application/x-openoffice-dif;windows_formatname="DIF"
debug:11537:11537:   text/plain;charset=utf-16
debug:11537:11537:   application/x-libreoffice-tsvc
debug:11537:11537:   text/rtf
debug:11537:11537:   text/richtext
debug:11537:11537:   application/vnd.oasis.opendocument.text-flat-xml
debug:11537:11537:   text/plain;charset=utf-8
debug:11537:11537:   text/plain

Ctrl+V
debug:11537:11537: setContents m1 c1 o1
=> we set the current selection (m1) with our stuff

debug:11537:11537: handleChanged m1 qo1
=> selection (m1) has changed, we own it and it has a lot of stuff in it:

debug:11537:11537:   application/x-openoffice-embed-source-xml;windows_formatname="Star Embed Source (XML)"
debug:11537:11537:   application/x-openoffice-objectdescriptor-xml;windows_formatname="Star Object Descriptor (XML)"
debug:11537:11537:   application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile"
debug:11537:11537:   application/x-openoffice-emf;windows_formatname="Image EMF"
debug:11537:11537:   application/x-openoffice-wmf;windows_formatname="Image WMF"
debug:11537:11537:   image/png
debug:11537:11537:   application/x-openoffice-bitmap;windows_formatname="Bitmap"
debug:11537:11537:   image/bmp
debug:11537:11537:   text/html
debug:11537:11537:   application/x-openoffice-sylk;windows_formatname="Sylk"
debug:11537:11537:   application/x-openoffice-link;windows_formatname="Link"
debug:11537:11537:   application/x-openoffice-dif;windows_formatname="DIF"
debug:11537:11537:   text/plain;charset=utf-16
debug:11537:11537:   application/x-libreoffice-tsvc
debug:11537:11537:   text/rtf
debug:11537:11537:   text/richtext
debug:11537:11537:   application/vnd.oasis.opendocument.text-flat-xml
debug:11537:11537:   text/plain;charset=utf-8
debug:11537:11537:   text/plain

debug:11537:11537: handleChanged m0 qo0
=> we get the information that someone has changed the clipboard (m0), Qt knows we're not longer the owner (qo0)

=> there is just this left in it:
debug:11537:11537:   text/plain
debug:11537:11537:   TARGETS
debug:11537:11537:   MULTIPLE
debug:11537:11537:   TIMESTAMP
debug:11537:11537:   SAVE_TARGETS

Consequently LO doesn't know anymore that a cell was copied, as text/plain is just the "1".

As you already found, if you disable the "Synchronize contents of the clipboard and the selection", no external "handleChanged m0 qo0" happens.

Now some additional background: nothing is normally in the clipboard or the selection. There is a reason I wrote (potential). The clipboard is like a client server connection, where the application that sets the clipboard becomes it's server. Other applications can ask for the list of content and then request what they prefer. The text editor prefers 'text/plain', the image program the 'image/png'. Real content is most time just generated on request. If the application shuts down it may really set the/some clipboard data, so it's not lost.
So normally you don't want to copy the whole clipboard on every change. It can get very expensive.

But there is a thing uncommon. On paste Calc creates a selection for the user, which is uncommon behavior. Creating the selection inside Calc is totally fine, but IMHO not the propagation to the system selection clipboard. After all the user is pasting, not selecting. OTOH gnumeric already sets the selection on copy, because it sets a selection.

BTW: here is what klipper is doing, when it creates an entry for the history (real code https://cgit.kde.org/plasma-workspace.git/tree/klipper/historyitem.cpp#n42)

HistoryItemPtr HistoryItem::create( const QMimeData* data )
{
    if (data->hasUrls())
       return urls
    if (data->hasText())
       return text 
    if (data->hasImage())
       return image
    return failed
}

That's it. All the nice additional mime-data is gone at this point.

So how to fix it:
1. Don't create a system selection when pasting in Calc (see https://gerrit.libreoffice.org/73906).
2. Create a real copy off all the QMimeData in klipper (NOTOURBUG). Feel free to open a KDE bug.

I'm not going to change Calc's behavior. But I'll add some Calc devs to the patch. Maybe they can decide...

Just to make it clear. After the first paste the selection is set correct, so even if the clipboard manager destroys the clipboard from the selection, you could now use the middle mouse button to "paste" cells. Not very obvious.

I just realized that there is currently an other uncommon behavior. Calc clears the PRIMARY when you remove a selection. So you select some cells in Calc, and the PRIMARY gets updated, then remove that selection by clicking somewhere else or using the arrow keys and Calc clears the PRIMARY. Normally an app / your text editor wouldn't clear the PRIMARY, just replace it when something else is selected. You can copy something empty to the CLIPBOARD but not the PRIMARY, as you can't select nothing, just unselect.

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/ee4953cf6c2d5106dd71c3488da9e3f41eafee84%5E%21

tdf#104717 don't set the primary selection on paste

It will be available in 6.4.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.