Download it now!
Bug 94882 - FILEOPEN: content of header of page style not visible on loading .doc file
Summary: FILEOPEN: content of header of page style not visible on loading .doc file
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: high major
Assignee: Luke Deller
Whiteboard: interoperability target:6.0.0 target:...
Keywords: bibisected, bisected, filter:doc, regression
: 90508 (view as bug list)
Depends on:
Blocks: DOC
  Show dependency treegraph
Reported: 2015-10-08 12:53 UTC by riccardo.arzenton
Modified: 2017-11-08 08:38 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

doc file with heading problem in LO (32.50 KB, application/msword)
2015-10-08 12:53 UTC, riccardo.arzenton
Simple ODT showing same first-page-header behaviour (9.48 KB, application/vnd.oasis.opendocument.text)
2016-10-06 11:31 UTC, Luke Deller

Note You need to log in before you can comment on or make changes to this bug.
Description riccardo.arzenton 2015-10-08 12:53:31 UTC
Created attachment 119419 [details]
doc file with heading problem in LO

LO handles badly the heading. The file should have one page setted with the "First Page" style with a classic heading with some paragraph and an image.
LO opens the file with the page setted in "Default Style" and no visible heading. If you change the page style to another one (for example "First Page") and then set back the "Default Style" the heading reappers.
Very strange.
Comment 1 Buovjaga 2015-10-09 15:19:38 UTC
Confirmed the badness.

It works correctly in 3.5!

Win 7 Pro 64-bit, Version: (x64)
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: fi-FI (fi_FI)

LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 2 Cor Nouws 2015-10-13 12:02:39 UTC
Open Styles and Formatting, page styles.
Double click on first page
 > nothing really changes
Double click on Default page
 > header content is back!

Comment 3 raal 2015-11-10 11:24:08 UTC
bibisect-win32-5.0, oldest version contains bug too.
git checkout oldest: Version:
Build ID: 57d6b92b69a31260dea0d84fcd1fc5866ada7adb
Comment 4 Cor Nouws 2015-11-10 13:15:11 UTC
first bad version I can track: 410beta1.

(My trick from comment #2 does not work in that version, by the way)
Comment 5 Joel Madero 2015-12-14 02:52:19 UTC
Moving to Major as it looks like data is missing when you open the file - even if there is a random workaround to make it come back.

a7e54955e9f49e8b59dfd8c4533785a680b1796c is the first bad commit
commit a7e54955e9f49e8b59dfd8c4533785a680b1796c
Author: Bjoern Michaelsen <>
Date:   Wed Oct 16 11:07:50 2013 +0000

    commit 5da10275a7475efdbfd9de14ea58cf8f4c6c1582
    Author:     Stephan Bergmann <>
    AuthorDate: Fri Mar 1 17:09:45 2013 +0100
    Commit:     Stephan Bergmann <>
    CommitDate: Fri Mar 1 17:18:29 2013 +0100
        Related rhbz#915743: Abort UCB call from SvtMatchContext_Impl::Stop
    otherwise the SvtMatchContext_Impl thread can continue to run for
        arbitrarily long, and the other thread calling Stop() and join() will block.
        However, especially the WebDAV UCP does not properly support aborting commands,
        see 260afe56fd6b2f34de8290f3cdb7d1df5b88f8a8 " neon commands cannot be aborted",
        so this is not yet enough to actually fix rhbz#915743 "thread deadlock/slow
        join in insert->hyperlink in impress."
        Change-Id: I0da899f824763e1b3d19bb5b38d906feb690b623

:100644 100644 fd22aadcebcf1ca20b6c2fcdb9e135deeb9b5885 8a0f14e1bb71d7ecdf8086c62e9769bb7f2d09b8 M	autogen.log
:100644 100644 5af869ab53b50329a270e7d4e2587f802bf68afb 8519bf956c5e06a85818d380070eedc0ef846790 M	ccache.log
:100644 100644 63cd7351c9d6feb098661a5783d51bb172d8a306 33abac29aad7182260562465482b493d94b78a83 M	commitmsg
:100644 100644 e9ea867065a69fa4f0fbbb5c2abb40baeeabd307 21fc5294b2cb922862b78327b6b8a3cd953f38b5 M	dev-install.log
:100644 100644 4c087a5ff52a8cef08f31417ac650666b1d9d0af c1cc87465560a589137349c81641a62968242386 M	make.log
:040000 040000 ece742cbaf9101d015210ea8da6c00ad7a4457c7 9ff9cbceea1fe6b0ad1b17fe9068b2c8e32a6cbb M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect bad e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [8f4aeaad2f65d656328a451154142bb82efa4327] source-hash-1885266f274575327cdeee9852945a3e91f32f15
git bisect good 8f4aeaad2f65d656328a451154142bb82efa4327
# good: [9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02] source-hash-8600bc24bbc9029e92bea6102bff2921bc10b33e
git bisect good 9995fae0d8a24ce31bcb5e9cd0459b69cfbf7a02
# bad: [8ad82bc1416a07501651e8d96fe268e47d3931d3] source-hash-13821254f88d2c5488fba9fe6393dcf4ae810db4
git bisect bad 8ad82bc1416a07501651e8d96fe268e47d3931d3
# bad: [238338bc4111eb82429ea47384d4012bcd7cdc3e] source-hash-b6ba04639b9922f6717f79ac4be215e09691d7a9
git bisect bad 238338bc4111eb82429ea47384d4012bcd7cdc3e
# bad: [89dc8a802d1625e0efd88ba0fb720b22be87f3f0] source-hash-da03bb1ee6a69d2f4fef4c3ca0adc0ba9588bd19
git bisect bad 89dc8a802d1625e0efd88ba0fb720b22be87f3f0
# bad: [fe956dc63cc7ed1831f0e7e9e7253ea4d8c99549] source-hash-b15f095293c6127ecaef2f0fa3a1683e72392835
git bisect bad fe956dc63cc7ed1831f0e7e9e7253ea4d8c99549
# good: [cd762eb968ba8783f726b67d9d70b0a76f4eb55d] source-hash-c9562064740baed3a9978723c5fe77b44a13a7aa
git bisect good cd762eb968ba8783f726b67d9d70b0a76f4eb55d
# bad: [a7e54955e9f49e8b59dfd8c4533785a680b1796c] source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582
git bisect bad a7e54955e9f49e8b59dfd8c4533785a680b1796c
# good: [5e90d936616ff95724eaa3e3a0a7c7a9747e9b44] source-hash-ba446dd58a4ad324d242afcd5b28d3b4dff5a881
git bisect good 5e90d936616ff95724eaa3e3a0a7c7a9747e9b44
# first bad commit: [a7e54955e9f49e8b59dfd8c4533785a680b1796c] source-hash-5da10275a7475efdbfd9de14ea58cf8f4c6c1582
Comment 6 Cor Nouws 2015-12-14 18:45:08 UTC
Might well be this one specific doc-file?

should sberg be asked?
Comment 7 Xisco Faulí 2016-10-05 16:14:27 UTC
Regression introduced by

author	Luke Deller <>	2013-02-09 15:31:47 (GMT)
committer	Tor Lillqvist <>	2013-02-11 10:41:05 (GMT)
commit	1e113cb7604e1509e7d598a9be329f1f7b6e9322 (patch)
tree	db4a3d3db3757364dd82da555d45e0add0c6bf1a
parent	532e25f8b0ef1daeca1f9f84c7084812b72841d5 (diff)

import different first page header/footer from doc
When a Word section has a different first page header/footer,
this used to be imported into LO as a chain of two page styles.
Now that LO supports a single page style with different first page
header/footer we can import to that.

This change also incidentally fixes fdo#57908.
bnc#654230 had the same underlying problem, so the workaround committed
for that (which includes comments expressing lack of understanding)
has been removed.

Adding Cc: to Luke Deller
Comment 8 Cor Nouws 2016-10-05 17:33:32 UTC
@justin: maybe you're interested too, since you did recent work in this area ?
Comment 9 Luke Deller 2016-10-06 11:31:57 UTC
Created attachment 127840 [details]
Simple ODT showing same first-page-header behaviour

The problem appears to be that the page numbers are set to start at page 50.  In MS Word, the first page of a section gets the "first page" header and footer regardless of the numerical value of the page number.  However it seems that in LibreOffice, the page does not get the "first page" heading of the page style because the page number != 1

I have attached a simple odt file which illustrates this same behaviour (fdo-94882-simpler.odt).

I feel like the LibreOffice behaviour is not right, and I would like to adjust this behaviour to match MS Word - but do others agree?  This behaviour is not specified in the ODF standard; it appears to relate to the following unresolved proposal:
Comment 10 Regina Henschel 2017-07-12 11:45:47 UTC
The ODT example file is not valid.
Comment 11 Luke Deller 2017-07-12 12:04:47 UTC
Thanks Regina - what exactly is the issue with it?  If I recall correctly it was created interactively in LibreOffice starting with a blank document, so if that can produce an invalid document in current builds then I may need to file another bug documenting steps to reproduce that issue.
Comment 12 Regina Henschel 2017-07-12 12:27:18 UTC
Attribute draw:fill not allowed --> bug 103602
Element <style:header-first> not allowed --> bug 109080
Comment 13 Commit Notification 2017-08-22 15:07:23 UTC
Luke Deller committed a patch related to this issue.
It has been pushed to "master":

tdf#94882 use first page header on first page

It will be available in 6.0.0.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 14 Xisco Faulí 2017-08-30 18:03:56 UTC
Verified in

Build ID: 78960ad06faca055a6d97afbc764c902d5d07f6f
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-08-30_06:31:19
Locale: es-ES (es_ES); Calc: group

@Luke, thanks for your work!! Could you please backport it to 5.4 ?
Comment 15 Commit Notification 2017-09-13 19:32:35 UTC
Luke Deller committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

tdf#94882 use first page header on first page

It will be available in 5.4.2.

The patch should be included in the daily builds available at in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 16 Justin L 2017-11-08 08:38:01 UTC
*** Bug 90508 has been marked as a duplicate of this bug. ***