Bug 115173 - EDITING: Drag to fill (Replicate) not always accurately replicating/updating cell references
Summary: EDITING: Drag to fill (Replicate) not always accurately replicating/updating ...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.4.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: AutoFill
  Show dependency treegraph
 
Reported: 2018-01-23 15:34 UTC by Colin
Modified: 2019-03-28 20:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Colin 2018-01-23 15:34:03 UTC
Description:
First I must apologise, I have no idea how to phrase the summary nor how to search for any existing reports which may be pertinent. I am experiencing situations where dragging a cell to replicate the contents doesn't always correctly assign the functionality. I have experienced two manifestations. One where some target cells failed to calculate when preceding and following cell copies perform as expected - the formula replicates ok but the result is null. I have copied, pasted, inserted and removed cells to no avail and ultimately simply retyped the formula which then resolved the issue. another successful ruse was to copy and paste the formula into a text document, clear the source and then copy and paste it back from the text document. Potentially indicates that when it thinks it is "importing" something it works. In one case for this example, I was replicating a large number of single column formulae over a substantial length and so paused to verify how far I had "travelled". There were multiple cells affected and it was necessary to search for the gaps to identify the failures. I Couldn't swear that it functioned perfectly if I just typed the target end cell reference and pasted the contents into the entire selection. I have had some success in resolving the issue by saving the sheet and then exiting and re-loading, at which point the glitch appears resolved.

The second manifestation is where a single formula is copied to just a small number of cells in the same column and despite the fact that the few adjacent cells referenced as sources for the calculation contain vastly different values the calculated results are identical. Again, copy, paste, insert, delete doesn't appear to "clear" the error condition and I must retype and repopulate the cells for it to function. It's almost as if the data/references become "locked" in the internal memory and despite the cell formulae appearing "normal" the function is not performed on an array and the first(or last, middle, random) elements of the array are then replicated to all the other affected cells. 35 cells each with a different adjacent source and the identical result. It's not the formula being "copied" it's the result of one calculation.  It's impossible to provide you with a malfunctioning sheet because it seems to clear when the sheet is closed.

Steps to Reproduce:
1. Indefinable, I'm hoping somebody reading the summary will understand and have half an idea where to start
2.
3.

Actual Results:  
Failed to correctly copy formulae and/or display the results

Expected Results:
repeated formulae with verifiable results


Reproducible: Sometimes


User Profile Reset: No



Additional Info:
[Information edited from LibreOffice] 
Version: 5.4.4.2 (x64)
Build ID: 2524958677847fb3bb44820e40380acbe820f960
CPU threads: 4; OS: Windows 6.19; UI render: default; 
Locale: en-GB (en_GB); Calc: group
Locale: en-GB
Module: Calc
[Information guessed from browser]
OS: Windows (All)
OS is 64bit: no



User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 raal 2018-01-23 19:16:33 UTC
Hello,

Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. 

Please provide a clearer set of step-by-step instructions on how to reproduce the problem.

Thank you
Comment 2 Colin 2018-01-23 20:01:43 UTC
The occurrence is too random to be able to provide step by step instructions. As far as I can tell it sometimes happens when I have a fairly large capacity multi-tab spreadsheet and have been manipulating it extensively so the potential number of undo and redo operations is substantial. I suspect it is memory management related because quitting and restarting regularly "clears" the issue. Consequently, a failing spreadsheet is not available because the anomaly disappears with the save and subsequent reload. I'm usually concentrating on figuring out how to get the sheet to do what I desire as opposed to systematically documenting what it's not doing correctly. In any event, how do you prove something doesn't/didn't happen? I mentioned that I suspect it's related to memory management in the hope that somebody might just have a eureka moment and relate the symptoms to an existing report or known "feature". Whilst writing I recall that sometimes it refuses to paste data with cut&copy from web pages. Again, the remedy is often (but not always)to cut & past something else and then try again with the desired data - or quit and reload.
As I am unable to be more specific than I have been and if nobody has the eureka moment then we probably have no alternative but to place the report on the "back burner" in anticipation of somebody else reporting something similar with more tangible evidence.
Comment 3 Buovjaga 2018-02-13 09:40:58 UTC
We must assume that there will be no eureka moment. Let's set to NEEDINFO, while we wait for you to come up with reliable steps to reproduce.
Comment 4 Gilward Kukel 2018-02-13 13:21:56 UTC
Could this be about this bug?:
https://bugs.documentfoundation.org/show_bug.cgi?id=115654
Comment 5 Colin 2018-02-13 15:20:23 UTC
Hi Gilward,
I believe this is the Eureka moment I had hoped for.
Whilst it is not identical, many of the aspects are the same.
I was indeed working on sheet 1, using drag to fill and the cells I referenced were the result of formulae where the calculation would dictate the offset to the current row.
I had allowed myself to think the trigger was possibly the fact that I was pausing in the drag to fill in order to expose more screen rows.
In my instance I wasn't getting an incorrect reference and result I was getting a null result - it was as though there was not even a formula in the cell. The omly reason it was spotted was because the data was being graphed and it was an improbability to have two zero results c1/3rd and c2/3rds along the axis in an otherwise densely populated chart with a couple of hundred events on the axis.
I am unable to confirm that saving and re-loading the sheet could have remedied the situation but I can identify that copying and pasting the formula from two or three rows above had no beneficial impact. Clearing the cell and physically retyping the formula was my successful remedy. In all honesty, my objective was to make the thing work rather than a critical path analysis of the error.
Well spotted sir.
Comment 6 Xisco Faulí 2019-03-28 18:53:33 UTC
Hello Colin,
A new major release of LibreOffice is available since this bug was reported.
Could you please try to reproduce it with the latest version of LibreOffice
from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to
'UNCONFIRMED' if the bug is still present in the latest version.
Comment 7 Colin 2019-03-28 20:30:04 UTC
(In reply to Xisco Faulí from comment #6)
> Hello Colin,
> A new major release of LibreOffice is available since this bug was reported.
> Could you please try to reproduce it with the latest version of LibreOffice
> from https://www.libreoffice.org/download/libreoffice-fresh/ ?
> I have set the bug's status to 'NEEDINFO'. Please change it back to
> 'UNCONFIRMED' if the bug is still present in the latest version.

Hi there, Xisco,
Just tried it with a far more complex "fill" with Release 6.1.5.2 and can no löonger reproduce the error.
I have changed the status to RESOLVED - WORKS FOR ME. I hope this is the correct course of action