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
Created attachment 163015 [details] How it looks in LibreOffice 7.1
Created attachment 163016 [details] not reproducible when the content is not on page 1
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
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.
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.
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.