Bug 146491 - FILEEXPORT DOCX: Unexpected hidden fields in DOCX document
Summary: FILEEXPORT DOCX: Unexpected hidden fields in DOCX document
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: low trivial
Assignee: Justin L
Whiteboard: target:7.4.0
Keywords: bibisected, bisected
Depends on:
Reported: 2021-12-30 19:18 UTC by Telesto
Modified: 2022-01-06 14:20 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Example file (30.54 KB, application/vnd.oasis.opendocument.text)
2021-12-30 19:18 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2021-12-30 19:18:25 UTC
UI: Unexpected mentioning of (hidden) fields in DOCX document

Steps to Reproduce:
1. open the attached file
2. File -> Save As DOCX
3. File reload
4. Sidebar -> Navigator -> Notice lots of Field number - 0

Actual Results:
Navigator is mentioning lots of hidden fields

Expected Results:
Question is hidden how, this isn't track changes hidden.

Reproducible: Always

User Profile Reset: No

Additional Info:
Version: (x64) / LibreOffice Community
Build ID: 1bb0e177124d5d6661b72df6c7d848fb23639652
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Telesto 2021-12-30 19:18:40 UTC
Created attachment 177213 [details]
Example file
Comment 2 Telesto 2021-12-30 19:29:07 UTC
I initially assumed a Navigator UI bug, but well this appears to be an export issue.

Fields are only visible in the navigator with a recent version of LibO. 

1. open the attached file
2. Export it to DOCX
3. Open the exported file with master or some recent version of LibO, notice the hidden fields

Hidden fields are exported with
Version: (x86)
Build ID: 5f01fe15eb2661f1f9ce12d1d99dc2a705b462ee
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL

but not with
Build ID: da49f4aeb8d5e9a7d2cba8855d911e7cc1d2f1e2
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL
Comment 3 zcrhonek 2021-12-31 08:00:58 UTC
I can confirm with Version: / LibreOffice Community
Build ID: c13db6e792cc347ffff4585f23866f195651f21f
CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded Jumbo
Comment 4 zcrhonek 2021-12-31 08:34:20 UTC
This seems to have begun at the below commit.
Adding Cc: to Justin Luth ; Could you possibly take a look at this one?
 6b7147f2c4c488b749216f7d0bb134d562ed266f is the first bad commit
commit 6b7147f2c4c488b749216f7d0bb134d562ed266f
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Dec 19 21:48:55 2018 +0100

    source e6f5dec3250b4d26bc4bb485fad2100ee29a3528

  tdf121374 ooxmlexport: export H/F to default section
Comment 5 Justin L 2022-01-03 12:57:58 UTC
An easier test is to look at the number of Page Styles. There are 11 Converted page-styles, while previously there were none. I expect that this field - contained in a footer - is being copied to each of these 11 styles.

This change occurred in 6.3 master, and backported to

The same is true for DOC format - probably since LO 6.3/
commit 0a6c609bdc89dd0317d3f5013c13d85d50d30669
Author: Justin Luth on Thu Jan 3 20:23:54 2019 +0300

    tdf#122429/tdf#122431 ww8export: export H/F to default section
    Just like bug 121374 for DOCX, which was just fixed in LO62,
    DOC apparently also sometimes can miss out on headers and footers.
    It wouldn't be terrible to duplicate headers/footers
    unnecessarily, but it is terrible to have them disappear.
    If the last SectPr has no idea about the section start,
    it can't know whether it is continuous or started with
    a page break. In that case, just ensure that the
    header and footer are explicitly written out.
Comment 6 Telesto 2022-01-03 15:51:38 UTC
From bug 146490 comment 3 (Jim Raykowski)
> The grayed out field seems to me to be a bug with header/footer handling of
> fields. We could sweep it under the carpet by not displaying fields in the
> header/footer that are in hidden state. What do you think? Maybe discuss in
> a separate ticket?

What's your opinion. Acceptable approach? In general not big fan of this type of workaround, but well it's a quick fix
Comment 7 Justin L 2022-01-06 13:59:06 UTC
This appears to be revertable. Something else must have altered the way sections/page styles are handled.

Proposed revert at http://gerrit.libreoffice.org/c/core/+/128041
Comment 8 Commit Notification 2022-01-06 14:15:54 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf146491 Revert "tdf121374 ooxmlexport: export H/F to def...

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ 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.