Bug 104717 - Repeated copy/paste is broken in Calc for KDE plasma "Clipboard contents" setting "Synchronize contents of the clipboard and the selection"
Summary: Repeated copy/paste is broken in Calc for KDE plasma "Clipboard contents" set...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.2.4.1 rc
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:6.4.0
Keywords:
Depends on:
Blocks: KDE, KF5 Paste
  Show dependency treegraph
 
Reported: 2016-12-16 15:53 UTC by Michal Svec
Modified: 2019-07-22 21:30 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Example spreadsheet (7.02 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-12-16 15:53 UTC, Michal Svec
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Svec 2016-12-16 15:53:10 UTC
Description:
How to reproduce:
- goto A2
- Ctrl+C
- goto B2
- Ctrl+V
-> "B1+1" is pasted (so far so good)

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


Steps to Reproduce:
-

Actual Results:  
-

Expected Results:
-


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 Michal Svec 2016-12-16 15:53:42 UTC
Created attachment 129697 [details]
Example spreadsheet
Comment 2 Michal Svec 2016-12-16 15:55:24 UTC
This is definitely a regression, it used to work just fine in the past.
(copy/paste is a rather key feature after all)
Comment 3 Cor Nouws 2016-12-16 16:42:49 UTC
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
Comment 4 m_a_riosv 2016-12-16 21:39:37 UTC
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
Comment 5 Michal Svec 2016-12-16 22:13:32 UTC
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.
Comment 6 Aron Budea 2016-12-16 22:30:59 UTC Comment hidden (obsolete)
Comment 7 Buovjaga 2016-12-18 18:34:12 UTC
(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
Comment 8 Michal Svec 2016-12-19 09:12:49 UTC
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?
Comment 9 Cor Nouws 2016-12-19 09:43:08 UTC Comment hidden (obsolete)
Comment 10 Michal Svec 2016-12-19 10:19:34 UTC
(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
Comment 11 Buovjaga 2016-12-28 17:58:11 UTC
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
Comment 12 QA Administrators 2017-12-29 03:28:39 UTC Comment hidden (obsolete)
Comment 13 Timur 2019-05-14 08:16:43 UTC
Please retest. I don't have KDE.
Comment 14 Buovjaga 2019-05-14 08:22:03 UTC
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
Comment 15 Jan-Marek Glogowski 2019-06-12 17:18:17 UTC
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...
Comment 16 Jan-Marek Glogowski 2019-06-22 20:20:42 UTC
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.
Comment 17 Jan-Marek Glogowski 2019-06-22 21:03:47 UTC
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.
Comment 18 Commit Notification 2019-07-16 17:06:15 UTC
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.