Description: Similar to the problem described here (https://bugs.documentfoundation.org/show_bug.cgi?id=129747), I just experienced the opposite problem: when displaying footnotes at the end of the document, the first six footnotes are nowhere to be found. Hovering over them shows them, but clicking on them does nothing. More than that: when I went to cleanse the document by doing a search-and-replace on letters and digits, those six footnotes were not cleansed. Displaying footnotes at the bottom of the page showed them, which allowed me to cleanse them. Setting footnotes back to end of document disappeared the first six footnotes again. Steps to Reproduce: 1. Open the attached document. 2. See that the first six footnotes are not displayed and are inaccessible. 3. Try doing a search-and-replace on the letter "a." All the displayed letters will be changed, but if you hover over the link to the first six footnotes, you'll see that they are not changed. 4. Set footnotes to display at bottom of page. See that the first six footnotes are now displayed. Actual Results: First six footnotes not displayed or accessible or editable. Expected Results: All footnotes should be displayed. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 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 threaded
Created attachment 191435 [details] Document showing the problem
As I was using the file on which this was based, I encountered a further issue. I set the footnotes to display at the bottom of the page so that I could edit one of them (footnote 4, for what it's worth). As I edited it, at some point it disappeared even when displayed at the bottom of the page. In order to get it back, I had to set footnotes to end of document (where it disappeared) and then back to bottom of page, where it reappeared. As I continued to edit, however, it disappeared again. Eventually I just copied the footnote to a blank document, finished editing it, and then pasted it back in. But the problem seems to be a deeper one with rendering of footnotes in tables, so perhaps identical to the issue underlying the bug linked in my initial report.
Possibly similar/related to https://bugs.documentfoundation.org/show_bug.cgi?id=153610?
I don't reproduce the issue on file open. However I can reproduce it in different way 1. Open attachment 191435 [details] 2. Go to second row of the table 3. Press Delete Row say 3 times 4. Press CTRL+Z 3x
Also in Version: 7.4.0.3 / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 8; OS: Mac OS X 13.4.1; UI render: default; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
You're right, in 7.6.4.1 on file open it looks good. Here's another way to reproduce a related problem. 1. Open the attachment. 2. Set Footnotes to bottom of page. 3. Go to the paragraph break at footnote 4. 4. Press enter a few times. 5. All footnotes disappear.
Also in Version: 7.1.8.0.0+ (x64) / LibreOffice Community Build ID: a94b58277c7aeaa83ce14347cd0b8f7137969d03 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL fine with Version: 7.0.7.0.0+ (x64) Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Bisected to: tdf#108820 sw layout: no ftn fieldshading in repeated header IsFootnoteAllowed() removes the footnote marker from the repeated table headers, but it didn't remove the view menu -> field shadings background. NewExtraPortion() is the only function that calls NewFootnotePortion(), and it will create a blank FieldPortion is nullptr is returned, so return a null FoonotePortion instead so that we can test for is-footnote and then prevent the drawing of the fieldshadings. FieldShading is an on-screen item only and never printed, so no unit test is possible. https://gerrit.libreoffice.org/c/core/+/99423
Steps to Reproduce: Open the attached document. Notice that the first six footnotes are not displayed and are inaccessible. Perform a search-and-replace on the letter "a." All displayed letters will change, but hovering over the links to the first six footnotes shows they remain unchanged. Change the footnote display setting to the bottom of the page. The first six footnotes will now be displayed. Actual Results: The first six footnotes are not displayed, accessible, or editable when set to display at the end of the document. https://planet-clicker.com
Created attachment 197723 [details] 158713_disappearingFootnotes.odt: minimal reproducer - created from scratch Steps to reproduce 1.) open document - notice that the table spills over onto page 2 2.) delete an empty paragraph in footnote 1's content. result: footnote 1 disappears when the rows on page 2 move back to page 1. [I also notice that if I instead first add some paragraphs (pushing footnote 2 to page 2), that deleting the paragraphs doesn't pull the footnote back to page 1 - already like that in 7.1). Everything can be reset by doing a print preview.
Sorry I didn't notice this earlier. I just stumbled across it now. Likely sounding functions MoveFootnotes, RemoveFootnotes and RemovePage/RemoveSuperfluous all didn't do anything. Avoiding a Join() stops it though. It is removed during SwTextFrame::DestroyImpl() with RemoveFootnotesForNode. Sadly, at this point SwTabFrame is already gone, so we can't even find out if it IsFollow() or if the row was a headline row. Oh, maybe it is as simple as return new SwFootnotePortion(u""_ustr, nullptr)? Nope. It doesn't care at all about pFootnote. It just asks if the text frame has been flagged with mbFootnote - which happens during SwFootnotePortion::Format. So either in there, or in SwTextFrame::SetFootnote I need to force mbFootnote to false.