Bug 147724 - The content of DOCX content control is no longer updated when opened (unless resaved in MSO)
Summary: The content of DOCX content control is no longer updated when opened (unless ...
Status: ASSIGNED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.0.3 release
Hardware: All All
: medium normal
Assignee: Vasily Melenchuk (CIB)
URL:
Whiteboard:
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Content_Control
  Show dependency treegraph
 
Reported: 2022-03-02 09:52 UTC by Martin
Modified: 2022-09-11 12:15 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
reproduction example (21.12 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-03-02 09:52 UTC, Martin
Details
example resaved in MSO (23.72 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-03-03 13:42 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin 2022-03-02 09:52:07 UTC
Description:
When I open a Word document with LibreOffice 7.3.0, the content controls are no longer updated. The old value remains, although a new value is contained in the DataBinding. This still worked with the old version 7.2.5.2. 

Steps to Reproduce:
1. Open the attached word document



Actual Results:
3. If the text "Placeholder -> HERUNTERLADEN" is displayed its wrong, this was the old value.

Expected Results:
3. If the text "Placeholder -> ABC" is displayed all works as expected


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.3.0.3 (x64) / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-AT (de_AT); UI: en-US
Calc: threaded
Comment 1 Martin 2022-03-02 09:52:41 UTC
Created attachment 178612 [details]
reproduction example
Comment 2 Timur 2022-03-03 13:36:21 UTC
Regression from 7.3.
commit e894e8559875e32657ffbdd2015c6471c7973942
    source sha:a4432eb0946c0bc775b3d30b634bef5d66544f8d
    prev c3d3eb7bdcb07824af7d205112f36201634aee59

author	Vasily Melenchuk <vasily.melenchuk@cib.de>	2021-11-24
commit a4432eb0946c0bc775b3d30b634bef5d66544f8d (patch)
tdf#104823: support for sdt plain text fields
Comment 3 Timur 2022-03-03 13:42:22 UTC
Created attachment 178639 [details]
example resaved in MSO

If reproduction example is resaved in MSO, LO opens it correctly.
Comment 4 Vasily Melenchuk (CIB) 2022-03-04 08:31:02 UTC
Problem is reproduced successfully.

Short analysis:

1. Since 7.3 LibreOffice is trying to evaluate databindings for sdt elements, like MS Word does. Before this was ignored, but since in customXml value for this sdt was identical to placeholder data in document.xml it was looking like everything okay.

2. I see that data binding xpath in this sdt element successfully resolves to "ABC" from customXml\item1.xml AND at the same time to "HERUNTERLADEN" from customXml\item2.xml. Since LO currently does not take into account w:storeItemID (not yet implemented) it can't distinguish which one value to use.

3. During resaving document in MS Word it can change order of custom xmls and so in LO we have different order of resolved data values. So it does helps only by accident.