Description: Previously, it was possible to provide the formula in a table cell with a cross-reference and then retrieve this in the subsequent text. If the result of the formula changed, the cross-reference in the text also changed. Now only cross-reference to the cell or formula is possible. If a cross-reference is setup to a cell with a formula, the formula is deleted and the result value of the previous calculation is entered - the table cell then no longer calculates. If an attempt is made to fill the area of a cross-reference with a formula, the cross-reference is deleted. For documents created with earlier versions, the cross-reference is deleted when the formula is recalculated. Steps to Reproduce: 1.Create a table with 1 column, 3 rows, fill in values in row 1+2 2.create a formula in row 3 (<A3>) that adds values from row 1+2 (= <A1>+<A2>) 3.change values in <A1> and/or <A2> 4.create/set a cross-reference on the formula in cell A3 (content will be doubled, one as cross-reference field) 5.insert cross-reference field outside the table (using referenced text); value from <A3> is shown 6. change values in <A1> and/or <A2> Actual Results: In step 3, the value in <A3> changes (because of the formula). In step 6, nothing changes in <A3> nor in the cross-reference outside the table. Expected Results: The formula in <A3> is working and cross referenced, so changes in <A1> and/or <A2> causing a recalc of <A3> which is shown in <A3> and outside the TAB in the cross-reference field Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.6.1.2 (X86_64) / LibreOffice Community Build ID: f5defcebd022c5bc36bbb79be232cb6926d8f674 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded
Please attach a sample file to test. I think it was already reported, but I can't find it now.
Created attachment 189882 [details] Test/example file to demonstrate the described misbehaviour in 7.6.x with LO writer 7.5.x: * change value #1 or #2 and the value in row 3 (sum formula) and in the cross-reference outside the table will change with LO writer 7.6.x: * change value #1 or #2 and the value in row 3 (sum) and in the cross-reference outside the table will NOT change * setting/resetting the cross-ref in row 3 will double content and does not work correct
Reproducible with Version: 7.6.1.2 (X86_64) / LibreOffice Community Build ID: f5defcebd022c5bc36bbb79be232cb6926d8f674 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded and master Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5e9c8d21874eea8cb5adf2ecab1905295af2308f CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo regression from Version: 7.5.7.1 (X86_64) / LibreOffice Community Build ID: 47eb0cf7efbacdee9b19ae25d6752381ede23126 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Repro in: Version: 7.6.3.0.0+ (X86_64) / LibreOffice Community Build ID: ba808a28f5ea365eaf8fe5d9c7c91b417633d75f CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded as well as recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e9374f74385d7dfe77d1902d3d82af20143bc775 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded So not a duplicate of bug 157394.
*** Bug 157490 has been marked as a duplicate of this bug. ***
Bibisected with linux-64-7.6 repository to first bad commit 31429d62c565e5064e09bf2349278bf0b571254b which points to core commit: commit 384a80fc56e75e3d1ee18ffc303db85490716829 author Matti Tyrväinen Mon Feb 13 21:04:56 2023 +0200 committer Miklos Vajna Fri May 19 12:28:35 2023 +0200 tdf#81720 Don't expand Reference Marks Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146941 Matti, can you please have a look?
Created attachment 190237 [details] Hotfix for 157287, unfixes 81720 without reverting refactoring and test > Matti, can you please have a look? As a single-time contributor with no prior C++ experience, I'm afraid the most I can offer right now is this patch that will restore the old reference mark behavior without reverting the UpdateFieldContent refactor nor removing the test case for tdf#81720. Two steps forward, one-and-a-half steps back...
Thanks Matti. Miklos, any opinion on this one?
The expand or not expand decision is hard to win, there will be always a situation where the old behavior was helping some use-case we forgot about. So restroing the old refmark behavior for now looks like a good idea. And the next person who wants to change this can now be aware of this catch, to do better. Thanks.
OK, thanks Miklos! Matti, please submit the patch on gerrit and we can then reopen bug 81720 with a note. Thank you!
> The expand or not expand decision is hard to win, there will be always a situation where the old behavior was helping some use-case we forgot about. So restroing the old refmark behavior for now looks like a good idea. And the next person who wants to change this can now be aware of this catch, to do better. Thanks. To clarify, the problem isn't whether the behavior helps a use-case, but whether it breaks existing functionality whose implementation depends on the old behavior. I feel this distinction between code changes' effect on UX, and their effect on other code, is worth stressing as their solutions differ. While both can be fixed by restoring the old behavior, implementation bugs can also be fixed by changing the implementation (eg. moving UpdateFieldContent into the object's scope) while workflow-breaking behavior changes would require changing the workflow. The new behavior should actually help in this use-case, as expanding the refmark in the cell by typing also stops it from updating, but until someone reworks the implementation behind the functionality used here, I agree that reverting it is appropriate. > Matti, please submit the patch on gerrit Done: https://gerrit.libreoffice.org/c/core/+/158059 Apologies for spamming Jenkins, couldn't test locally due to bump in GCC's required version.
(In reply to Matti Tyrväinen from comment #11) > Apologies for spamming Jenkins, couldn't test locally due to bump in GCC's > required version. If you have trouble there, please describe your actual problem on the dev mailing list or on #libreoffice-dev IRC and we'll try to help. It's not too complicated to install a new GCC even on older distros. Bugzilla is not ideal for this kind of interaction. :-)
(In reply to Matti Tyrväinen from comment #11) > Apologies for spamming Jenkins, couldn't test locally due to bump in GCC's > required version. If you use Debian or Ubuntu, see the note for how to get a newer GCC: https://wiki.documentfoundation.org/Development/BuildingOnLinux#Debian_and_Ubuntu
The patch has been reverted with 58e5e3208a4257a8d9f2e28d8e2d304677aa6980 and backported to libreoffice-7-6 Closing as RESOLVED FIXED
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bae0736bf0ec54828766c3d903e2a27458643395 tdf#157287: sw_core_txtnode: Add unittest It will be available in 24.2.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.