https://bugs.documentfoundation.org/show_bug.cgi?id=172184
--- Comment #13 from [email protected] --- Independent reproduction, a minimal fixture set that isolates the cause to one variable, and one consequence I don't think is captured yet. === 1. Reproduced on builds far older than 26.2.3.2 === LibreOffice 24.2.7.2 420(Build:2) Ubuntu 24.04, headless --convert-to pdf LibreOffice 25.8.7.3 580(Build:3) Ubuntu 24.04, headless --convert-to pdf Identical wrong output on both. So "earliest affected" is considerably earlier than 26.2.3.2 and this is not a recent regression. === 2. It is the numeric id VALUE, not the array/element order === The description offers both possibilities ("based on their literal physical index array order or ID values"). Four 10 KB fixtures, generated by pandoc so they open clean in Word, distinguish them. Each has four existing footnotes (ids 20-23) plus one NEW note inserted at document position 1, whose body reads "THIS IS THE NEW NOTE (should be number 1)". Only two things vary: the new note's w:id, and where its <w:footnote> element sits in footnotes.xml. fixture new id element position note 1 renders as A-control-no-insertion (none) - ALPHA (correct) B-id24-element-LAST 24 last ALPHA WRONG C-id24-element-IN-POSITION 24 first ALPHA WRONG D-id19-element-LAST 19 last THE NEW NOTE (correct) B vs C -- only the ELEMENT POSITION changes; both wrong. => array/serialisation order is NOT the variable. B vs D -- only the w:id changes (24 -> 19); B wrong, D correct. => the numeric id VALUE is the variable. In every one of B, C and D, `pandoc -f docx` resolves note 1 to "THE NEW NOTE", i.e. the keyed reading. Microsoft Word (M365, Windows) also renders these correctly. Attaching all four. === 3. The mispairing is WRITTEN BACK TO DISK on export -- this is data loss === This is the part I'd flag for severity. It is not only a rendering fault. Running .uno:AcceptAllTrackedChanges on an affected file (headless, via a Basic macro over UNO) and saving as .docx produces a file in which LibreOffice has RENUMBERED the footnote ids sequentially according to its own incorrect reading and re-serialised footnotes.xml to match. Measured on both 24.2.7.2 and 25.8.7.3, identical outcome: paragraph footnote body now attached to its mark "Sentence ALPHA is first." THIS IS THE NOTE FOR ALPHA <- should be the inserted note "Sentence ALPHA is first." THIS IS THE NOTE FOR INSERTED "Sentence INSERTED is second." THIS IS THE NOTE FOR BRAVO "Sentence BRAVO is third." THIS IS THE NOTE FOR CHARLIE "Sentence CHARLIE is fourth." THIS IS THE NOTE FOR INSERTED-BY-ADD-FOOTNOTE The exported file is internally self-consistent, so Microsoft Word then displays the WRONG pairing faithfully -- verified in Word (M365). The original association is unrecoverable from that file. Residual w:ins/w:del count is 0 and the XML validates, so nothing downstream flags it. So for any workflow that round-trips a DOCX through LibreOffice, a rendering bug becomes silent, permanent content corruption. In a footnoted scholarly or legal document that means citations permanently attached to the wrong propositions, with no signal to the author. === 4. Possible lineage === This looks like a residual of the fix for tdf#153255 ("footnotes swapped when editing a MS Word document", commit ed0372ba, 2023-03-21). That commit message says the previous code broke on files "where serialization in footnotes.xml doesn't follow the order of the footnotes" -- i.e. element-order dependence was replaced by id-order dependence, where ECMA-376 requires neither. Both tdf#153255 and tdf#162918 bisect to 9b39ce0e ("tdf#76260 DOCX import: fix slow footnote import"), so this whole family descends from that rewrite. Expected behaviour, restating the description's own conclusion: resolve each <w:footnoteReference w:id="X"/> encountered in document.xml order against footnotes.xml by id EQUALITY, ignoring both numeric magnitude and element position. === 5. Triage note === This report is filed under Component "LibreOffice" rather than "Writer", and DOCX-Footnote-Endnote is in "See Also" rather than "Blocks". It therefore does not appear in the DOCX-Footnote-Endnote dependency list, where someone looking for exactly this bug would expect to find it. That may be why it is still UNCONFIRMED. Suggest moving to Writer and setting Blocks: DOCX-Footnote-Endnote, RTF-Footnote-Endnote. -- You are receiving this mail because: You are the assignee for the bug.
