Bug 118599 - EDITING: Paste uses wrong data
Summary: EDITING: Paste uses wrong data
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.7.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-06 23:57 UTC by Jeff Laramie
Modified: 2019-01-23 23:07 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Sheet displaying bug (9.46 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-07-09 20:41 UTC, Jeff Laramie
Details
Screenshot of correct formula (1.69 MB, image/png)
2018-07-09 23:04 UTC, Jeff Laramie
Details
Screenshot of screwed up formula (1.69 MB, image/png)
2018-07-09 23:12 UTC, Jeff Laramie
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Laramie 2018-07-06 23:57:04 UTC
I've had this problem for months but it is such a big issue I assumed it had to be me or my hardware. Today it manifested itself in a different way and I don't see how it could be anything I'm doing.

When copying or cutting then pasting a cell or cells the previously selected data is used instead of the currently selected data. In other words it pastes the previous entry on the clipboard instead of the current one. This does not happen all the time but it does happen most of the time. Sometimes it doesn't recognize the data that's being pasted and will ask what format it should be pasted as.

I can reproduce this on different Calc spreadsheets but no other programs are affected and pasting works normally for Thunderbird, kwrite and other programs.

Another manifestation is that occasionally when selecting and overwriting a data range in the formula bar the beginning of the range is replaced with the ending range and the ending range becomes a very large unrelated number. This happens randomly but on average about 1 out of 20 times.

Today the third and most serious manifestation occurred. I copy and pasted a range of cells containing formulas and they appeared fine. Then I noticed that the data in the first cell had a value that couldn't be right. The formula contained a range of values divided by an integer (creating an average of the values). When you highlighted the cell the correct range and formula appeared but the value was wrong. It appears that when it pasted the cell range the beginning range updated correctly but the ending range didn't change so that the pasted range now contained the incorrect number of cells.

This is a big deal since there is no way to know then the formula value is wrong. The formula in the bar is correct but the underlying data references the wrong range.

Here's the specific version I'm using:
Version: 5.3.7.2.0+
Build ID: 5.3.7.2-3.mga6
CPU Threads: 8; OS Version: Linux 4.14; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: en-US (en_US.UTF-8); Calc: group

This may be related to bug 99763.
Comment 1 Jeff Laramie 2018-07-09 20:41:59 UTC
Created attachment 143406 [details]
Sheet displaying bug

Sheet is self-explanatory. As you can see when using shortcut keys everything works as expected. The problem arises when the copy/cut source is selected with the mouse and copied/cut using the right click mouse menu. It appears that every other copy/cut action selects the previously selected data.
Comment 2 Jeff Laramie 2018-07-09 23:04:37 UTC
Created attachment 143412 [details]
Screenshot of correct formula

These 2 screenshots show the 2nd manifestation of this issue. I can't send you the spreadsheet, but here's a screenshot. The formulas in the column with the highlighted cell were modified by highlighting the row number of the first cell in the formula bar and replacing it with a different row number. The divisor was also modified the same way to reflect the new range.
Comment 3 Jeff Laramie 2018-07-09 23:12:55 UTC Comment hidden (obsolete)
Comment 4 Jeff Laramie 2018-07-09 23:28:09 UTC
(In reply to Jeff Laramie from comment #3)
> Created attachment 143413 [details]
> Screenshot of screwed up formula
> 
> This screenshot shows the next cell in the column. The data was modified
> exactly the same as in the first screenshot, but look at the how the formula
> was saved. The end of range became the beginning of the range and the end of
> the range became the beginning of the range plus the first character of the
> divisor. The 2nd and 3rd characters of the divisor are now the 1st 2
> characters and a seemingly random 20 is added to the end of the divisor.

After looking at this more I think the 20 that was added to the divisor was not random but was the characters in the divisor that were highlighted and supposed to be replaced.
Comment 5 Jeff Laramie 2018-07-10 00:25:04 UTC
I've tried to update this to critical but the system won't let me. I know it's very unlikely a problem of this magnitude could make it into a major release and I'm still hoping this is something specific to my system, but as I look into this, that seems less and less likely. This is looking more like a memory allocation issue and an extremely serious one at that. This issue results in corrupted data and sometimes it is undetectable by the end user. I know you get hundreds of bug reports and most are bogus, but please don't blow this off.
Comment 6 Xavier Van Wijmeersch 2018-07-14 20:18:37 UTC
I suggest
reset your user profile and upgrade LO to 5.4.7.2 or 6.0.5.2
retest the behavior because i cannot reproduce the problem

Version: 6.2.0.0.alpha0+
Build ID: 187af5be47db42e2f4ab94319f932b847f897ce2
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: gtk3; 
Locale: nl-BE (en_US.UTF-8); Calc: group threaded
Comment 7 Jeff Laramie 2018-07-14 20:42:04 UTC Comment hidden (obsolete)
Comment 8 raal 2018-07-15 08:09:37 UTC
(In reply to Jeff Laramie from comment #7)
> To be clear, when you say reset my user profile you're saying I should
> delete the files in ~.config/libreoffice?

Hello,
see https://wiki.documentfoundation.org/UserProfile
Comment 9 Jeff Laramie 2018-07-15 18:00:01 UTC
Using safe mode had no effect on this bug and I've ruled out a corrupted profile as the cause.

I was unable to reproduce this on a different Mageia 6 laptop that had not been updated recently. I wiped the old installation and reinstalled Mageia 6 on the laptop. Now that the updated version 5.3.7.2-3.mga6 is installed I can reproduce it on both machines.

I've filed a bug report with Mageia for this:
https://bugs.mageia.org/show_bug.cgi?id=23304

Please keep this bug report open until we are able to determine the root cause.
Comment 10 Jeff Laramie 2018-07-16 13:32:32 UTC
Version 5.4.7.2 from your site does not contain the bug.
Comment 11 Xisco Faulí 2019-01-23 15:35:52 UTC
(In reply to Jeff Laramie from comment #10)
> Version 5.4.7.2 from your site does not contain the bug.

Do you mean the problem is no longer reproduced with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
Comment 12 Jeff Laramie 2019-01-23 21:35:08 UTC
(In reply to Xisco Faulí from comment #11)
> (In reply to Jeff Laramie from comment #10)
> > Version 5.4.7.2 from your site does not contain the bug.
> 
> Do you mean the problem is no longer reproduced with the latest version of
> LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?

I have not tried the newest version, but 5.4.7.2 was the newest version at the time I tested, and it did not contain the bug. I have only been able to replicate this bug using a Mageia packaged version running the KDE desktop. Other desktops and versions work fine. It does not appear to be related to your code and this bug report can be closed.
Comment 13 raal 2019-01-23 23:07:57 UTC
Closing