Bug 137060

Summary:	VIEWING Cells with formula not correctly updated after change of source value
Product:	LibreOffice	Reporter:	Stefan_Lange_KA <Stefan_Lange_KA>
Component:	Calc	Assignee:	Not Assigned <libreoffice-bugs>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	aron.budea
Priority:	medium
Version:	7.1.0.0.alpha0+
Hardware:	x86-64 (AMD64)
OS:	Windows (All)
Whiteboard:
Crash report or crash signature:		Regression By:
Attachments:	zip file with document to reproduce the bug and screenshots

Description Stefan_Lange_KA@T-Online.de 2020-09-26 18:00:42 UTC

Created attachment 165876 [details]
zip file with document to reproduce the bug and screenshots

Cells with formula values are not correctly updated when source values are changed. More precisely: Some (one or few) but not all cells with formula depending on a source value are updated after a change of the source value.
The cells are update later e.g. when the document is saved or when the cells are redrawed after roll them out and in.
 
How to reproduce (2 ways):
First way:
- open document "Test_Formula_(Corona_Statistics).ods" from attached zip file
- select rows with "Deutschland" in column A via autofilter
- change value in cell B7 e.g. by deleting the leading "8" from "83.517.046" to "3.517.046"
- result: values in cells D42, E42, I42 and J42 are updated but the values in D59/D76, E59/D76, I59/I76 and J59/J76 remain unchanged -> see screenshots 1 and 2
- scroll downwards that visible rows are rolled out to the top and scroll upwards to roll in the rows rolled out before
- result: The values in cells D59/D76, E59/D76, I59/I76 and J59/J76 are updated now -> see screenshot 3
Second way:
- open document "Test_Formula_(Corona_Statistics).ods" from attached zip file
- select the rows from 87 to 103 and insert rows above -> 17 empty rows are inserted (87...103) 
- select rows from 70 to 85 and copy them to the clipboard
- insert clipboard content into the empty rows 87 ... 103 inserted before
- change value in cell B87 - e.g. to the current date
- result: From the cells in column K (set by formula to the value of B87) omly K88 is updated, all other (visible) cells are unchanged -> see screenshots 4 and 5
- scroll downwards that rows from 87 to 103 are rolled out to the top and scroll upwards to roll in the rows rolled out before
- result: All values in cells K88 ... K103 are updated now -> see screenshot 7
 
The bug was found in LOdev 7.1 but earliest version with the bug is 7.0.2 rc1:
Version: 7.0.2.1 (x64)
Build ID: ede20268f3f8777cdf69e0281835d320c41213fc
CPU threads: 4; OS: Windows 10.0 Build 20221; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
In version 7.0.1 and earlier versions (LO 3 ... LO 6) I cannot reproduce the bug.

Comment 1 Stefan_Lange_KA@T-Online.de 2020-10-02 04:42:14 UTC

The bug is also present in
Version: 7.0.2.2 (x64)
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 4; OS: Windows 10.0 Build 20226; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL

Comment 2 Stefan_Lange_KA@T-Online.de 2020-10-03 20:04:16 UTC

Regression:
-----------
I have checked when the bug was introduced.
In LOdev 7.1.0.0alpha0 the bug was introduced in the build from 2020-09-11.
The behavior described is first time reproducible with
Version: 7.1.0.0.alpha0+ (x64)
Build ID: ed4f610f4a3de12016f8308a17b6ad4f86e9d67a
CPU threads: 4; OS: Windows 10.0 Build 20226; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
In earlier builds of LOdev 7.1 (until 2020-09-10) I cannot reproduce the bug.

In LO 7.0 the bug was introduced with the build LO 7.0.2 rc1 from 2020-09-2018 and the first LOdev 7.0.3 build from 2020-09-21. In all builds of LOdev 7.0.2 (until 2020-09-16) the bug doesn't occur.

Addtion to the second way to reproduce the bug (easier way):
After open the test document "Test_Formula_(Corona_Statistics).ods" one can change the date value in one of the cells in column B and look what happens in the following rows with the date values in column K.

Comment 3 Aron Budea 2020-10-17 18:16:42 UTC

Stefan, I haven't tried to repro, but this looks like a dupe of bug 137248. If you can't reproduce it with a fresh daily build, let's leave it at that, otherwise feel free to reopen.

*** This bug has been marked as a duplicate of bug 137248 ***

Comment 4 Stefan_Lange_KA@T-Online.de 2020-10-17 20:00:25 UTC

I have tested with
Version: 7.0.3.0.0+ (x64)
Build ID: 2a8cd72be8045ff90bad87acb884c5c96ca96ed2
CPU threads: 4; OS: Windows 10.0 Build 20236; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: CL
from https://dev-builds.libreoffice.org/daily/libreoffice-7-0/Win-x86_64@tb77-TDF/2020-10-16_08.00.25/
and with
Version: 7.1.0.0.alpha0+ (x64)
Build ID: df74aef7159d7155addf78cfc4d139485945d794
CPU threads: 4; OS: Windows 10.0 Build 20236; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
from https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb77-TDF/2020-10-16_05.06.12/

With both builds I can't reproduce the bug, means it is resolved really and the bug can be left closed.