Bug 134592 - FILEOPEN DOCX : Common domain has compatibility problems
Summary: FILEOPEN DOCX : Common domain has compatibility problems
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3 all versions
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Miklos Vajna
URL:
Whiteboard: target:7.2.0 target:7.1.1
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2020-07-07 02:31 UTC by NSO LibreOffice Team
Modified: 2021-02-09 10:06 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (13.76 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-07-07 02:31 UTC, NSO LibreOffice Team
Details
How it looks in LibreOffice 7.1 (31.08 KB, image/png)
2020-07-14 11:48 UTC, Xisco Faulí
Details
not reproducible when the content is not on page 1 (15.52 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-07-14 11:57 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NSO LibreOffice Team 2020-07-07 02:31:17 UTC
Created attachment 162737 [details]
Example file

Description:
Using libreoffice document to open the common domain test document (docx), there is a compatibility problem (Create Time and current time and Number of words and Number of characters).

Steps to Reproduce:
1.Using libreoffice document to open the common domaintest document (docx)
2.There is a compatibility problem


Actual Results:
Create Time and current time and Number of words and Number of characters are incorrect

Expected Results:
Common domain remains unchanged


Additional Info:
Version Infomation
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 4c14c88cc681abab787a461a1bea502a777f37e6
CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: zh-CN (zh_CN); UI: en-US
Calc: threaded
Comment 1 Xisco Faulí 2020-07-14 11:48:56 UTC
Created attachment 163015 [details]
How it looks in LibreOffice 7.1
Comment 2 Xisco Faulí 2020-07-14 11:57:41 UTC
Created attachment 163016 [details]
not reproducible when the content is not on page 1
Comment 3 Xisco Faulí 2020-07-14 11:59:37 UTC
it seems like a timing issue, since the problem is no reproducible when the content is not on page 1.

Not sure whether it's a regression but the issue when the content is on page 1 started to happen after

https://cgit.freedesktop.org/libreoffice/core/commit/?id=fdacaab2485fa42648ae96348b9ad6a9e1f49424

author	Miklos Vajna <vmiklos@collabora.co.uk>	2014-03-21 15:31:21 +0100
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2014-03-21 15:47:24 +0100
commit	fdacaab2485fa42648ae96348b9ad6a9e1f49424 (patch)
tree	b77c47d8bec671b40934f0fb57ca96e921a0ccf0
parent	706893eb2d737e1475945f4204f95b7382992240 (diff)
DOCX import: implement progressbar

Bisected with: bibisect-43max

Adding Cc: to Miklos Vajna
Comment 4 Miklos Vajna 2021-02-02 15:43:59 UTC
Here is my understanding of the situation:

1) the progressbar has nothing to do with this, apart from slightly modifying the visible area of the document after open

2) the fields are updated because once wordcounting finishes, all stats fields are updated. Now document metadata has a single "is modified" flag, so whenever stats change, all metadata (stats, doc info) is re-calculated, including the creating time, even if it's not metadata

3) one concrete fix that can be done here is to lock down the "creation date" field: that will obviously not change, and it's a docx import bug that the importer requests it to be updated (because that's the default in Writer, but "no update" is Word's default), loosing the formatting on open

I'll take care of 3), and let's reduce the scope of this bug to just that. Please open a separate, non-regression bug for the rest. Thanks.
Comment 5 Commit Notification 2021-02-09 08:03:18 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3b928391b3398c1113e675ea6a542d05d9611e0a

tdf#134592 DOCX import: preserve formatting of CREATEDATE fields

It will be available in 7.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 6 Commit Notification 2021-02-09 10:06:25 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-7-1":

https://git.libreoffice.org/core/commit/793fc8c7c70faec4e6c1e9ad0c4d9f47193a181c

tdf#134592 DOCX import: preserve formatting of CREATEDATE fields

It will be available in 7.1.1.

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.