Bug 145594 - Inserting Footnotes in Writer Tables Breaks Formulas
Summary: Inserting Footnotes in Writer Tables Breaks Formulas
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.5.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-11-09 05:17 UTC by William Friedman
Modified: 2023-09-17 10:22 UTC (History)
2 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 William Friedman 2021-11-09 05:17:01 UTC
Description:
If I have a table with numbers in Writer, and insert footnotes in any of the cells, it breaks any formulas that try to use the data in the cell with the footnote.

Steps to Reproduce:
1. Create a simple table with one row and three columns.
2. Put numbers in the first two cells.
3. Put the formula =SUM(<A1:B1>) in the third cell.
4. Insert a footnote after the number in the first cell.

Actual Results:
The formula in the third cell no longer adds the number in the first cell.

Expected Results:
The formula in the third cell should still add the number in the first cell, disregarding the footnote.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.5.2 (x64) / LibreOffice Community
Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 1 Deep17 2021-11-12 04:35:30 UTC
I can reproduce the bug in 

Version: 7.2.2.2 (x64) / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

I cannot reproduce this issue in 

Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 73334560b2dd2d60ac58d2cc2b1a5295490b03e1
CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

However I found one issue where the summation does not happen when you change the value in the cell which has footnote.
Comment 2 Deep17 2021-11-15 21:27:55 UTC
Below are the steps to reproduce the issue what I have identified in the master build.
1. Create a simple table with one row and three columns.
2. Put numbers in the first two cells.
3. Put the formula =SUM(<A1:B1>) in the third cell.
4. Insert a footnote after the number in the first cell.
I can see the defect as expected
Additional steps mentioned below shows a different behavior.
5. place another number after the footnote
6) clicking on the third cell does not change the result as expected.
7) change the number in the 2nd cell (cell without the footnote) and click on the 3rd cell, which shows the result as expected.
Comment 3 Nii 2021-11-28 09:55:09 UTC
Thank you for reporting the bug, 

I cannot reproduce the bug in

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: ec76fff198323122bedc63ffdfd896c2543102c6
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: fi-FI
Calc: CL

or 

Version: 7.2.2.2 (x64) / LibreOffice Community
Build ID: 02b2acce88a210515b4a5bb2e46cbfb63fe97d56
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: fi-FI (fi_FI); UI: fi-FI
Calc: CL
Comment 4 William Friedman 2021-12-07 05:28:40 UTC
Thank you both. I just tried it on:

Version: 7.2.3.2 (x64) / LibreOffice Community
Build ID: d166454616c1632304285822f9c83ce2e660fd92
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

and indeed the bug was fixed. However, I noticed is a strange discrepancy in behavior, related to what Deep17 wrote:

In the absence of a footnote, when I change the number in one of the first two cells, the sum in the third cell changes as soon as the cursor leaves the changed cell. So, for example, if I have 1 and 1 in the first two cells, and change one of them to 2, then the sum in the third cell changes to 3 as soon as I leave the changed cell, either by tabbing to another cell or clicking outside the table.

However, in the *presence* of a footnote, if I change the number in the cell with the footnote (either by changing the existing number or adding a number after the footnote), then the sum in the third column *does not change* if I tab to another cell or click outside the table. It only changes *once I return to the table itself*, by clicking on any of its cells, or by adding another row. (Changing the number in the cell without a footnote *does* result in immediate recalculation of the sum, as in the normal behavior.)

This delayed reevaluation of the sum in the presence of a footnote seems to be an important bug, too, since as far as I can tell the reevaluation doesn't happen unless one happens to click out of it and then back into the table. Should I file a different bug report for this?
Comment 5 Buovjaga 2022-01-04 15:42:09 UTC
(In reply to William Friedman from comment #4)
> However, in the *presence* of a footnote, if I change the number in the cell
> with the footnote (either by changing the existing number or adding a number
> after the footnote), then the sum in the third column *does not change* if I
> tab to another cell or click outside the table. It only changes *once I
> return to the table itself*, by clicking on any of its cells, or by adding
> another row. (Changing the number in the cell without a footnote *does*
> result in immediate recalculation of the sum, as in the normal behavior.)
> 
> This delayed reevaluation of the sum in the presence of a footnote seems to
> be an important bug, too, since as far as I can tell the reevaluation
> doesn't happen unless one happens to click out of it and then back into the
> table. Should I file a different bug report for this?

Yes, I think it would be best to create a new report.
Comment 6 William Friedman 2022-01-04 21:48:18 UTC
New bug submitted here: https://bugs.documentfoundation.org/show_bug.cgi?id=146573

Thank you!