Created attachment 134492 [details] A test file with 2 pages with page numbers in footers' paragraph-attached text boxes Attachment has page number in text box in each of two pages in Word. When open in Writer, it only has page number in 1st page, the second page has empty footer. The problem is that the second section in document inherits the footer from first section, so LibreOffice copies the footer data between page styles on import (SectionPropertyMap::CopyLastHeaderFooter), and the functions that do real job (DocumentContentOperationsManager::Copy[Range|Impl]) do not copy last paragraph's anchored objects.
Created attachment 134496 [details] Minimal testcase with inherited footer with text box This is a better sanitized example.
Confirmed in Version: 6.0.0.0.alpha0+ Build ID: 7931ef2abbcef22de5cdddd26738e4dd8d1d8ca5 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and Version: 4.4.0.0.alpha0+ Build ID: f340f0454627939f1830826fb5cc53a90e6c62a4 in previous version, the footer is not even displayed on the first page.
Sounds similar to bug 104237 - anyone brave enough to tackle one of these is welcome to also look at the other one.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro 6.5+.
In reply to Justin L from comment #3) > Sounds similar to bug 104237 attachment 134492 [details] still not fixed in master 7.0, not even by bug 112202
Looks OK, WFM, rebisect desired (I came up with that word to stand for reverse bibisect, should be in LO nerd's dictionary).
fixed by commit c12358166a9bd88fe10feabca45a6ad3f65dff8e Author: Miklos Vajna on Fri Jan 10 16:03:43 2020 +0100 DOCX import: fix lost objects anchored to an empty linked header This is really similar to commit 04b2310aaa094794ceedaa1bb6ff1823a2d29d3e (DOCX import: fix lost objects anchored to the single para of a linked header, 2020-01-10), except here the header is not just a single-paragraph one, but has no text portions. Update text-copy.docx to have a header which is not only a single paragraph, but also has no character content. This keeps testing the original case, but now also tests the more strict case (single paragraph -> single empty paragraph).