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
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.
Could be something GTK3-related?
(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 Michal Svec from comment #8) > 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. Thanks for finding this! > 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?
(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 read this message in its entirety before responding ** 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 http://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 MassPing-UntouchedBug
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.