Take an ODT created in previous version of LO (say a 3.6 version), where the ODT has headers that differ on left/right pages, and where the first header after a page-break is on the left-hand page. Open this ODT in 4.0.0.3. The new header option 'Same content on first page' is ticked, both on the default page style and on all custom page styles. This makes the first header the RIGHT-HAND header, even though it's on a left page. Changing the 'Same content on first page' option afterwards has no effect - the first header is already corrupted. Only solution is not to save in 4.0.0.3 and use a previous version to edit, which means that 4.0.0.3 can never be used to edit this document, or to correct all the first headers manually. ----- Sorry, no attachment - affected document is private.
We do need some kind of test document for this. Please strip your document of private data and upload it. Marking as NEEDINFO, once test document is attached please open the bug as UNCONFIRMED and I will look at the test document. Thanks for your understanding, our QA team is just too stretched to manually reproduce test documents so we request the test document to easily see the problem. Plus this we we know that we are seeing the exact same problem.
Created attachment 74188 [details] Example of corrupted header Here we are, Joel. I've created a Lorem Ipsum based on the private document. The document was created in LO 3.6.5. Open the document in 3.6.5 and all the headers are correct. Open it in 4.0.0.3 and the header on page 4 (a right-hand page) appears as a left-hand header - it gets the chapter-number field and the page-number appears on the incorrect side. Incidentally, I then tried to create the same incorrect header in chapter two, by deleting (using 3.6.5) the last two paragraphs of chapter one (thus forcing the first header in chapter two to be on a right-hand page) but the whole document then appeared correct in 4.0.0.3, including the page four header!
I added Bug 60256 to the 'See Also' fields because of the very similar problems (although I only can reported/can reproduce the behavior I mentioned there using docx-format). Therefore I don't mark this as duplicate. Kind regards, Joren
The results of a few experiments I've done: - If I save, using LO 4.0.0.3, the attached example file in Flat XML (.fodt) format, and reopen that .fodt file, then LO 4.0.0.3 shows the correct headers. (Same result with the longer private file). - Using LO 4.0.0.3, I can get the correct headers to appear in the original .odt file (as attached) by editing some of the styles in the document, but if I save the document and then reopen that .odt file, the corrupt header is back. - If I make a trivial edit to the attached example file in LO 4.0.0.3 (so that the corrupt header is still showing) and save it, then reopen it in an old version (LO 3.5.4 is what I used), then the header appears fine. This implies that no data is being corrupted, it's just that LO 4.0.0.3 is *showing* the header incorrectly, but only if the file is .odt. If the file is .fodt, then the header appears correctly. It *seems* to follow (guessing here!) that the left/right-ness of the first header is calculated wrongly when an .odt file (but not an .fodt file) is *opened*. Note too that the incorrect headers get exported to PDF, so it's not just a question of what's onscreen being incorrect - the incorrect headers are in some sense there in LO 4.0.0.3.
Noticed Jorendc's bug (60256, in the See Also) has been solved in Version 4.1.0.0.alpha0. So I tried this in latest Version 4.1.0.0.alpha0 but this bug REMAINS. Test version used: Version 4.1.0.0.alpha0+ (Build ID: a4b4c0cdae9695f49d41f097fb891845b8e908f)
I see even worse behavior now, I see the word BROKEN in the header with Version 4.1.0.0.alpha0+ (Build ID: 6c89f2e74aa9b202d6d6a41a178ba9aadb2b10e) Date: Mon Feb 18 23:22:17 2013 +0100 but in 3.6.5.4 it looks perfectly fine. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Further findings, if you save as with LibreOffice 4 and then open new saved document in LibreOffice 3.6.5.4 it appears fine. Marking as: New (confirmed) Normal (there is no data loss but something is definitely going on) High (normal feature, interoperability with 3.6, regression) Regression Bibisectrequest
Not sure how helpful this bisect will be, the behavior is different (more like how reporter says), but maybe at least get some code pointers in there: 703554f1f068dc8d60909fe49ac2bfae4aadc3f8 is the first bad commit commit 703554f1f068dc8d60909fe49ac2bfae4aadc3f8 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Mon Dec 10 17:35:45 2012 +0000 source-hash-a20f9a410fdd3f776f870434bc39219d5fc64b40 commit a20f9a410fdd3f776f870434bc39219d5fc64b40 Author: Noel Grandin <noel@peralex.com> AuthorDate: Wed Oct 3 13:30:43 2012 +0200 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Thu Oct 4 16:29:53 2012 +0200 fdo#46808, Adapt xml::sax::XParser UNO service to new style The xml.sax.Parser service already existed, it just did not have a new-style service to create it. Change-Id: I6f145a7504ff9e149c802f723991954a2801cbc9 :100644 100644 0a2166bae9c838b1ac4f1361e629291f0e0aba13 b7cb5c5fc3c41b6ca5d400137367b19efc4fe28f M ccache.log :100644 100644 b3c11b723c8354b9dc7295f75b1ae1b424d6d096 5680cdb04b35639f2f1400c66ccab14ba64f2eb6 M commitmsg :100644 100644 a213961f2cad89295bf28a98cb969c734b2b4f24 26cc768956bad2d9c4be9b25f6c827aa40310762 M dev-install.log :100644 100644 a9d40710f309e3236c9c349c956ffe5cd22784d0 dc6d136e4e7c26263bb36a56b13593cd3e167296 M make.log :040000 040000 2907b4766ceb9ee3ef7c9f33674a843fe97cac8d af5af3dece0683344483358662d76fa272363a73 M opt # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262 # good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea # good: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f git bisect good 7e20e241c1d8819d8d5edb7894baeddde33f9d3a # bad: [62b2ae5ee4cc77ad0b399c5a716ef526023d13ab] source-hash-e9960f36675a025c0536dec30ae56c50f4adecb1 git bisect bad 62b2ae5ee4cc77ad0b399c5a716ef526023d13ab # bad: [703554f1f068dc8d60909fe49ac2bfae4aadc3f8] source-hash-a20f9a410fdd3f776f870434bc39219d5fc64b40 git bisect bad 703554f1f068dc8d60909fe49ac2bfae4aadc3f8 # good: [45e7bb384016f066ab30a844087af64f2420415b] source-hash-9ed34f8137e1ec4f58151eba74507102192cb8fd git bisect good 45e7bb384016f066ab30a844087af64f2420415b
In the bibisect range, this commit looks kinda suspicious: commit a964cf666abb0c4df4e29ea8709532b7d45c104f Author: Miklos Vajna <vmiklos@suse.cz> Date: Thu Oct 4 08:23:12 2012 +0200 sw: proper fallback for first page in InsertNewPage() For left/right share, the fallback is easy: the left page always falls back to the right page, if there is a fallback. In case of first page, the situation is more complicated, as there are multiple fallbacks (left/right). Since commit 9ff68a2, first page fallback was decided during registering part of the SwPageDesc to SwPageFrm, which is bad, as without a document export/import, a changed IsFirstShared() didn't have any effect: the LeftFmt/RightFmt was in use, so FirstFmt had no SwClients -> nobody was notified when that setting changed. This commit changes first pages to always use FirstFmt, and (if a fallback is needed) sets FirstFmt to point to LeftFmt/RightFmt as necessary. Change-Id: I4654baf293d72070fcf7e9eea408a43a31079e60 thus ccing Miklos ...
it appears this commit lets the header on page 4 show up correctly after load: http://cgit.freedesktop.org/libreoffice/core/commit/?id=4dc78aee9bcdb6ea5e9dc47ebb4a4b9e590c725a please test with a master build that includes that (tomorrow perhaps, was just comitted) if you still see any problems.
I can confirm that the latest Master has indeed solved the problem - not only on the small example file but also on the private file, which is thousands of pages long and had around 50-ish incorrect headers, all of which are now corrected. Many thanks for sorting this out, Michael. Will this fix go into the 4.0 series? Is it too late to make 4.0.2? Is it ok for the reporter (me) to mark this 'resolved'?
Marking as duplicate. Sorry, I meant to look into this, but Michael beat me, so even if it's not logical to mark this bug a duplicate of a bug that was reported later, I'm doing so. ;-) *** This bug has been marked as a duplicate of bug 61952 ***