Created attachment 87241 [details] Removed page count field See attached test files (ODT: before, DOCX: after).
Created attachment 87242 [details] Restored page count field by DOCX export
Created attachment 87243 [details] Removed input field with change tracking
Created attachment 87244 [details] Restored input field by DOCX export (with deleted content)
This bug is lacking reproduce steps. My guess: 1. open first test file (I see "1" but that is deleted using "Track changes") 2. store as docx file 3. open docx file with LO Currently: "1" is back there but without the Track changes info that it has been deleted Expected: docx should have identical info as the odt file has. Sidenote: opening the docx file with Word shows the track changes delete info. So this is def. a LO bug and as it looks not on the export side of things, but rather in correctly interpreting the exported information in docx files. OSX 10.10.3 + LO Version: 4.5.0.0.alpha0+ Build ID: 09a1e4f36128f64029d45a38d9b059bf11ea0821 TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-04-15_23:40:09 Locale: de_ Confirmed (since this has never been confirmed before, but was on NEW already for whatever reason).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
So the problem here is that the <w:del> tag is only being placed around the first run element, rather than the entire group of run elements related to the field. How it used to be in 4.0 <w:del ... w:id="0"> <w:r> <w:rPr></w:rPr> <w:fldChar w:fldCharType="begin"></w:fldChar> </w:r> <w:r> <w:instrText>PAGE</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate" /> </w:r> <w:r> <w:delText>1</w:delText> </w:r> <w:r> <w:fldChar w:fldCharType="end" /> </w:r> </w:del> How it is in 4.1 and above <w:del ... w:id="0"> <w:r> <w:rPr></w:rPr> <w:fldChar w:fldCharType="begin"></w:fldChar> </w:r> </w:del> <- the problem happens here <w:r> <w:instrText>PAGE</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate" /> </w:r> <w:r> <w:t>1</w:t> </w:r> <w:r> <w:fldChar w:fldCharType="end" /> </w:r>
Comment 6 covered attachment 87241 [details] and the page number field. Things are worse for attachment 87243 [details] and the input field. Similar to the page number field, in 4.1 the <w:del> tag is only being placed around the first run element for the input field, but in 4.2 and above the entire field gets removed from export. 4.1 <w:pPr> <...> <w:del ... w:id="0"> <w:r> <w:rPr></w:rPr> <w:fldChar w:fldCharType="begin"></w:fldChar> </w:r> </w:del> <-- the 4.1 bug mentioned in comment 6 <w:r> <w:instrText>FILLIN "example"</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate" /> </w:r> <w:r> <w:t>Example</w:t> <w:br /> </w:r> <w:r> <w:fldChar w:fldCharType="end" /> </w:r> <w:r> <w:rPr></w:rPr> <w:fldChar w:fldCharType="begin"></w:fldChar> </w:r> <w:r> <w:instrText>FILLIN "example"</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate" /> </w:r> <w:r></w:r> <w:r> <w:fldChar w:fldCharType="end" /> </w:r> </w:p> 4.2 and above <w:p> <...> <w:del w:id="0" ...> <w:r> <w:rPr></w:rPr> </w:r> </w:del> <w:r> <w:rPr></w:rPr> </w:r> </w:p> @Xisco, @Raal, @Terrence: Would appreciate if any of you could bibisect both the 4.1 regression and 4.2 dataloss.
So it seems that even the ooxml code exported in 4.0 for the input field file is reported to be invalid when opened in MS Word and its likely because the field is being exported both in the <w:del> tag as well as outside of it. <w:p> <...> <w:del ... w:id="0"> <w:r> <w:rPr></w:rPr> <w:fldChar w:fldCharType="begin"></w:fldChar> </w:r> <w:r> <w:instrText>FILLIN "example"</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate" /> </w:r> <w:r> <w:delText>Example</w:delText> <w:br /> </w:r> <w:r> <w:fldChar w:fldCharType="end" /> </w:r> </w:del> <!-- the w:r elements below shouldnt be there -> <w:r> <w:rPr></w:rPr> <w:fldChar w:fldCharType="begin"></w:fldChar> </w:r> <w:r> <w:instrText>FILLIN "example"</w:instrText> </w:r> <w:r> <w:fldChar w:fldCharType="separate" /> </w:r> <w:r></w:r> <w:r> <w:fldChar w:fldCharType="end" /> </w:r> </w:p>
@Yosuf, I do not understand enough about the bug. STR, detailed enough to allow for my very small experience with track-changes, might help. Does comment 9 mean that the 4.1 regression is really older than 4.1? My oldest bibisect repository is 41max. Terry.
(In reply to Terrence Enger from comment #9) > I do not understand enough about the bug. STR, detailed enough to > allow for my very small experience with track-changes, might help. 1) Open attachment 87241 [details] 2) Save it as a .docx 3) Close document 4) rename the .docx to .zip 5) Unzip file 6) Open /word/document.xml 7) Search for </w:del> and see if its followed by </w:p> 8) If it is then regression hasnt occurred yet > Does comment 9 mean that the 4.1 regression is really older than 4.1? > My oldest bibisect repository is 41max. The 4.1 regression happened after 4.0 was branched so 41max should find it. For the dataloss that happened in 4.2, here are the steps 1) Open attachment 87243 [details] 2) Save it as a .docx 3) Close document 4) rename the .docx to .zip 5) Unzip file 6) Open /word/document.xml 7) Search for FILLIN 8) If it is found then regression hasnt occurred yet
Created attachment 133218 [details] bibisect results for 4.1 regression Thank you, Yosuf, for those STR. A result that can be checked without user interaction works wonderfully with `git bisect run`. Working in the bibisect-42max repository on debian-stretch, I see that the 4.1 regression happened somewhere in the 33 source hashes ... commit s-h date -------- -------- ---------- good 940934b5 db1118a6 2013-11-06 bad d8ba9023 a09f7fdd 2013-11-07 (I expect to be able return to bibisecting in about five hours, unless somebody else gets here first.) Terry.
Created attachment 133224 [details] bibisect results for 4.2 dataloss Working in the 42max bibisect repository on debian-stretch, I see ... commit s-h date -------- -------- ---------- good 9c9229dd 06ed06d2 2013-11-19 bad d0d8af75 c2b55219 2013-11-19 I am removing keyword bibisectRequest and adding bibisected (not "bisected" because of range determined for 4.1 regression).
Thanks Terrence for the bibisecting.
Hi Terrence, Which is the correct range of commits, comment 11 or comment 12 ?
Xisco, The behaviour of LibreOffice got worse in two stages. Yosuf in c#7 describes the stages with the output markup at each stage; in c#10 he gives STR at each stage. So, I think c#11 and c#12 are both correct, just for different problems. Does this help? Is there something more that I can do?
@Tamas, @Mike, @Justin: Any of you guys want to take this on?
(In reply to Terrence Enger from comment #11) > bibisect results for 4.1 regression > Working in the bibisect-42max repository on debian-stretch, I see that > the 4.1 regression happened somewhere in the 33 source hashes ... > commit s-h date > -------- -------- ---------- > good 940934b5 db1118a6 2013-11-06 > bad d8ba9023 a09f7fdd 2013-11-07 The most likely commit seems to be cp#1000015 DOCX export: fix not-well-formed XML on redline end + hyperlink https://cgit.freedesktop.org/libreoffice/core/commit/?id=7813bd3113beb2b2860f9eb213c5c67ef54f5bf0 However, this section of code has completely changed, so it won't be trivial to resolve. The commit identified in comment 12 is the very large commit "Resolves: #i33737# enable in-place editing of Input Fields" https://cgit.freedesktop.org/libreoffice/core/commit/?id=c2b5521921b806ff7b04cdacebde3834d2aafd4b
Created attachment 136944 [details] even without track-changes active, the field doesn't get exported to .docx
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Working with debian-buster and daily Linux dbgutil bibisect repository version 2018-10-30, commit 2e184378: Version: 6.2.0.0.alpha1+ Build ID: 2e184378da6058af14acf208d6469fadf44d04ed CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-CA (en_CA.utf8); Calc: threaded I still see both bugs.
Part of the problem was the bad (missing) import, fixed in https://gerrit.libreoffice.org/#/c/73397/
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/d160bca0dcb80f1b517b79221d5c3a43bbad8639%5E%21 tdf#70234 DOCX: import tracked deletion of fields It will be available in 6.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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/caf2f5fff39caf06204f71d0c2276b415ef047c3%5E%21 tdf#70234 DOCX: export tracked deletion of fields It will be available in 6.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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/222f6a1c43b7ae7bf8e2f1fbc1dbe6457e611ab7%5E%21 tdf#70234 DOCX export: fix only expanded fields It will be available in 6.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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/fe317b8d0845657703803d51e16f01e529740ef0%5E%21 tdf#70234 DOCX: import tracked deletion of fields It will be available in 6.3.0.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.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/1d9513ee4036c5af93a263aeb173dbc7d74e843e%5E%21 tdf#70234 DOCX: export tracked deletion of fields It will be available in 6.3.0.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.
Verified in Version: 6.4.0.0.alpha0+ Build ID: 0d6ec494f83fb26524bf3a5fc7af27c225293e87 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @László Németh, thanks for fixing this issue!
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/7dc4f5d686f7834702ff133b4e75f29ffa6b5ec3%5E%21 tdf#70234 DOCX export: fix only expanded fields It will be available in 6.3.0.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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/f5a5afc7f6525a07c124e154e2c727a6985f4044%5E%21 tdf#70234: This change didn't get cherry-picked It will be available in 6.3.0.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.