Description: After undoing a "find & replace all" the cells with an automatic result are stuck with the result obtained after the find & replace whereas the undo action has been working. Steps to Reproduce: 1. Enter 513 in cell A1 2. In cell B1 enter "=A1/12" (it will display 42.75) 3. Hit Ctrl+H 4. Find 513 5. Replace all by 625 6. The value of B1 is now 52.0833333 7. Hit Ctrl+Z Actual Results: 8. The value of B1 is still 52.0833333 Expected Results: 8. B1 should have a value of 42.75 Reproducible: Always User Profile Reset: Yes Additional Info: Tested on: Version: 6.4.5.2 Build ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 162761 [details] Testing FIle Here is a file with some examples. You can try with any value, the bug will always occur.
Also experimented on: Version: 7.1.0.0.alpha0+ Build ID: 088b7f419f48f3390aac22587bbd92e9e027d5b1 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Confirmed. It lacks one recalculation of the Undo value, entering a new value in A1 after that recalculates.
Found already in 5.3, don't know if earlier. Not in OOo3.3
Created attachment 163125 [details] details of the strace command After a quick bibisection, the bug seems to be introduced between LO 4.0.6.2 and LO 5.1.1.3. I'm experiencing some issues while starting the versions between those mentioned above... ------------ $> ./opt/program/soffice --version LibreOfficeDev 4.1.0.0.beta1 3a2c2d2417101e45fe07cfd8358acf2204a98f3 $> ./opt/program/soffice [[ LO Loading splashscreen display ]] javaldx: Could not find a Java Runtime Environment! Warning: failed to read path from javaldx ** (soffice:27006): WARNING **: 16:53:04.815: Unknown type: GailWindow [[ HERE the application stops and the progress bar isn't complete ]] $> strace ./opt/program/soffice ... [see file attached to more details]
The bug was introduce in LO 4.2.0.0.beta1.
Hi all, There is a patch for this issue. It can be reviwed here: https://gerrit.libreoffice.org/c/core/+/101535
Bibisect results in repo bibisect-42max, the following range is a single commit in the bibisect repo: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=ac84ffb3c90bb5788608eadf2177f587021daaad..4c99a427ee4adaeddb2682c192384bad21d9d09b
(In reply to Pierre Marty from comment #7) > Hi all, > > There is a patch for this issue. > > It can be reviwed here: > https://gerrit.libreoffice.org/c/core/+/101535 Update at the same link
Still reproducible in: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 95e6f942b3fa5c6f3e5473ac474a4702ab815502 CPU threads: 4; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN Calc: threaded Adding bug 141619 as see also (may be a duplicate, but I am not very sure).
Following the similar bisect steps as in https://bugs.documentfoundation.org/show_bug.cgi?id=141619#c8 I have bisected this bug to the same commit as in bug 141619, i.e. commit c008dc483f8c6840803983e7e351cec6fdd32070 Author: Kohei Yoshida <kohei.yoshida@gmail.com> Date: Fri May 24 11:52:18 2013 -0400 Switch to using multi_type_vector for cell storage. Since they appear to be the same bug behaviour (formular reference > find and replace > undo > auto calculate not updated), I mark this as a duplicate of bug 141619. *** This bug has been marked as a duplicate of bug 141619 ***