Bug 168858 - Conditional Sections Are Improperly Set to 0 When Opened With LibreOffice
Summary: Conditional Sections Are Improperly Set to 0 When Opened With LibreOffice
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
25.8.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:26.2.0 target:25.8.4
Keywords:
Depends on:
Blocks:
 
Reported: 2025-10-14 19:37 UTC by Damian
Modified: 2025-11-06 19:29 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of Broken section (510.77 KB, image/png)
2025-10-14 19:38 UTC, Damian
Details
Bug form (108.41 KB, application/vnd.oasis.opendocument.text)
2025-10-14 19:42 UTC, Damian
Details
Minimized FODT (842 bytes, application/vnd.oasis.opendocument.text)
2025-10-23 05:48 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Damian 2025-10-14 19:37:20 UTC
Description:
When there are conditional sections next to each other, not wrapped in a table, one of the conditions is changing to 0 when the odt is opened with Libreoffice 25.8, or converted to a pdf using soffice in LibreOffice 25.8. In the content.xml file we can see the condition is: "" EQ "". This is correct, but when the odt is opened in LibreOffice 25.8, that section changes to 0. The affected section is not always the same, depending on the order and how many there are.

In the attached screenshot and odt we can see the condition is 0, but it should be: "" EQ "", as it is in the content.xml.

Steps to Reproduce:
1. Have conditional sections within <office:body> and <office:text> in the content.xml that aren't wrapped in anything else with the condition of: "" EQ "".

2. Open the odt in LibreOffice 25.8, or use soffice to generate the pdf using LibreOffice 25.8. One or more sections will be 0 when they weren't 0 in the content.xml.

Actual Results:
The condition on the section in the xml was "" EQ "", but when opening the odt in LibreOffice it was 0.

Expected Results:
Instead, the section should have been hidden(True) as the condition should have stayed as "" EQ "".


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Attachments are important to show this issue
Comment 1 Damian 2025-10-14 19:38:59 UTC
Created attachment 203332 [details]
Screenshot of Broken section
Comment 2 Damian 2025-10-14 19:42:26 UTC
Created attachment 203333 [details]
Bug form
Comment 3 abhishah4444 2025-10-14 19:44:58 UTC
We would also like to see if you have any pointers, how can we debug this to identify root cause, which would help us to understand impact. As simply removing certain lines from XML is causing issue to go away so we need some help to understand to identify scope of impact on our other working forms as well.
Comment 4 Damian 2025-10-15 21:09:42 UTC
UPDATE: I have noticed that in the xml there are "text:is-hidden" attributes in the <text:section> elements. According to odf 1.4 schema(the one LibreOffice 25.8 uses), or any other odf scehma version there is no "text:is-hidden" attribute in <text:section> elements.

Link to odf schema I am referencing: https://docs.oasis-open.org/office/OpenDocument/v1.4/cs01/part3-schema/OpenDocument-v1.4-cs01-part3-schema.html#__RefHeading__1415162_253892949.

Thinking this comment will be of some use in debugging.
Comment 5 abhishah4444 2025-10-16 13:07:19 UTC
ODT works fine in  7.6.7.2 & 6.4.7.2 and section stays hidden unlike 25.8.2.2 & 24.8.3.2 so seems like its broken recently
Comment 6 Mike Kaganski 2025-10-23 05:48:49 UTC
Created attachment 203492 [details]
Minimized FODT

Repro.

(In reply to abhishah4444 from comment #5)
> ODT works fine in  7.6.7.2 & 6.4.7.2 and section stays hidden unlike
> 25.8.2.2 & 24.8.3.2 so seems like its broken recently

Wrong. The difference is only which sections show the problem; it is also reproducible with 7.6 and 7.4 and 7.4.

Regression after commit 868b45039d2d168e1c51d971b0d1e0589d4d11eb.
Comment 7 Mike Kaganski 2025-10-23 05:58:11 UTC
The code introduced there was removed in ca3e88728f29422ad9e4bd7f9bec08b59cdf4192. Still, the 0 is shown even in current master. It is possible, that the bisect result from comment 6 is also wrong, and it was another oscillation of the display of the problem, not the true cause.
Comment 8 Mike Kaganski 2025-10-23 10:07:26 UTC
https://gerrit.libreoffice.org/c/core/+/192902
Comment 9 Commit Notification 2025-10-23 14:30:33 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0856a6a4dfcb00c63fcc13c116f570a2d6c4ca57

tdf#168858: drop workaround for hidden last section

It will be available in 26.2.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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2025-10-24 07:29:43 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-25-8":

https://git.libreoffice.org/core/commit/74384758e93792d16bf4af712ba39b36d1c78c70

tdf#168858: drop workaround for hidden last section

It will be available in 25.8.4.

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:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 abhishah4444 2025-11-06 19:29:51 UTC
We have tested thoroughly and fix for this bug seems like working. We found more than 1 forms where hidden section was appearing and with bug fix it is fixed.