Created attachment 67055 [details] Sample document to illustrate formatting bug when deleting a paragraph Deleting a complete paragraph with "track changes" (redlining) enabled applies the paragraph style of the paragraph being deleted to the following paragraph. Reproduce: The attached document Redline_delete_paragraph.odt has a chapter heading and 2 text paragraphs. Turn on "track changes" if it is turned off (and also enable "show changes", if necessary). Delete the first paragraph with the chapter heading by marking the complete text line "Delete this paragraph including new-line and save file" _plus_ the following "character" (i.e. the new-line marker). Either save the file or disable "show changes". The text paragraph following the deleted paragraph is reformatted in the heading paragraph style of the deleted paragraph. When you save the document as DOC, you can delete the entire first paragraph without having the following paragraph reformatted. (If you disable "show changes" for the DOC file, the bug shows again, however.) The only way to retain the format of the document as it's supposed to be is - either to delete only the text part of the paragraph - but then after accepting all tracked changes there remain all those empty paragraphs in the document; - or to change the format of the paragraph to be deleted before deleting it (to the format that the following paragraph should have) - which is undesirable if you reject the tracked changes or want to view the deleted text properly. I am reporting this bug for LO 3.4.4/Linux 64bit, but has been present in OpenOffice and LibreOffice for years.
reproducible with LO 3.6.4.3. (Win7 Home, 64bit) But actually these are two cases with bugs. Case 1: Select in the attached sample text with left mouse clicking beginning with the word "Delete" until the end of the first paragraph ending with the word "simultaneously", but do not stop and go on with the mouse into the next line before the word "Whether", but without selecting this following line or this word "Whether" (the cursor should blink before the "W" of the word "Whether"). Then delete the selected text and the deletion will be shown by the record changes function. Now save this file and you will see that the following paragraph will be reformatted to Heading 1. It is necessary to save this file. If you would accept the changes before saving then the bug would not occur. Case 2: Select in the attached sample text with left mouse clicking beginning with the word "Delete" until the end of the first paragraph ending with the word "simultaneously", but now do not go to the next line, stop after the word "simultaneously" (the cursor should blink after the "y." of the word "simultaneously"). Then delete the selected text and the deletion will be shown by the record changes function. For this case it does not matter whether you save the file or not. Then accept the changes. Afterwards, you will see an empty line before the new first paragraph which is also formatted as Heading 1.
*** Bug 61239 has been marked as a duplicate of this bug. ***
Reproduced with Version 4.0.1.4. and 3.5.3 on Win7. Hence Platform changed to "All".
Reproducable with Version 4.1.2.3 and 4.1.3.2 on Win7 Remark to case 2: This behaviour is independent of "track changes" (redlining) enabled or not.
** 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.4 or later) 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-01-17
Bug still exists in version 5.0.4 with Win7.
Still reproducable with Version 5.0.6.3 on Win7. Tested according to comment#1 and comment#4.
Still reproducable with Version 5.3.1.2 (x64) on Win7. Tested according to comment#1 and comment#4.
** 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
Faulty behaviour still present with Version 6.0.3.2 (x64) Build-ID: 8f48d515416608e3a835360314dac7e47fd0b821 CPU-Threads: 8; BS: Windows 6.1; UI-Render: Standard; Gebietsschema: de-DE (de_DE); Calc: group on Win7. Tested according to comment#1 and comment#4. Additionally retested it with old version LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 on Win7. It was present, therefor version changed to 'inherited from OOo'.
László Németh committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=22639148ae5400bac98f32a75d7431b857c80195 tdf#54819 change tracking: keep paragraph style after full deletion It will be available in 6.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Tested both cases (see comment#1) with Version: 6.2.2.2 (x64) Build-ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: CL: Case 1: When deleting the heading of the first paragraph as described in comment#1 case 1, the format of the heading is reset from heading 1 to text. This is not correct. If you want to cancel the change, the sentence will not be rebuild with the correct format, it remains in the text format. This is not correct. Case 2: When deleting the heading together with the first paragraph as described in comment#1 case 2, the format of the heading is reset from heading 1 to text, too. This is not correct. Furthermore you can't roll back with <CTRL>-Z in both cases. If you want to cancel/revert the change, the heading marked for deletion will not be rebuild to the correct format, it remains in the text format. This is not correct. It should stay in the same format if it is marked to be deleted.
(In reply to Jürgen Sanne from comment #12) > Tested both cases (see comment#1) with Version: 6.2.2.2 (x64) > Build-ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d > CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; VCL: win; > Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE > Calc: CL: > > Case 1: > When deleting the heading of the first paragraph as described in comment#1 > case 1, the format of the heading is reset from heading 1 to text. This is > not correct. > > If you want to cancel the change, the sentence will not be rebuild with the > correct format, it remains in the text format. This is not correct. > > Case 2: > When deleting the heading together with the first paragraph as described in > comment#1 case 2, the format of the heading is reset from heading 1 to text, > too. This is not correct. > > Furthermore you can't roll back with <CTRL>-Z in both cases. > > If you want to cancel/revert the change, the heading marked for deletion > will not be rebuild to the correct format, it remains in the text format. > This is not correct. It should stay in the same format if it is marked to be > deleted. I can confirm all your observations. But why did you change this bug to VERIFIED WONTFIX?
(In reply to Harald Koester from comment #13) > (In reply to Jürgen Sanne from comment #12) > > Tested both cases (see comment#1) with Version: 6.2.2.2 (x64) > > Build-ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d > > CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; VCL: win; > > Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE > > Calc: CL: > > > > Case 1: > > When deleting the heading of the first paragraph as described in comment#1 > > case 1, the format of the heading is reset from heading 1 to text. This is > > not correct. > > > > If you want to cancel the change, the sentence will not be rebuild with the > > correct format, it remains in the text format. This is not correct. > > > > Case 2: > > When deleting the heading together with the first paragraph as described in > > comment#1 case 2, the format of the heading is reset from heading 1 to text, > > too. This is not correct. > > > > Furthermore you can't roll back with <CTRL>-Z in both cases. > > > > If you want to cancel/revert the change, the heading marked for deletion > > will not be rebuild to the correct format, it remains in the text format. > > This is not correct. It should stay in the same format if it is marked to be > > deleted. > > I can confirm all your observations. But why did you change this bug to > VERIFIED WONTFIX? Was it wrong? What would be the expected status? REOPEN?
Sorry, I had chnaged the bug to a wrong status. REOPENED is the better choice.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b69c518df68ce673b28d589da6626bd3d860f309%5E%21 tdf#54819 keep style & numbering at tracked deletion 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.
Now the improved workaround supports Undo (Ctrl-Z), so the behavior of wholly paragraph deletion is the same as without change tracking: the paragraph after the deletion keeps its style, numbering and direct formatting, without inheriting the direct and other formatting of the deleted paragraph. Currently the workaround needs style copying for the deletion, losing the original style of the first paragraph of the deletion at saving. This needs an other bug report (and there are a few of them already: see Bug 125311 and Bug 125984 about numbering). [As a similar, but original problem, the recent OpenDocument implementation of LibreOffice doesn't support rejection of tracked formatting only changes, see Bug 58813.]
The deleted paragraph changed its style in Version: 6.3.1.0.0+ Build ID: 8b81a453b22611f25674f5e44ae411d78c2fcada 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 but not in Version: 6.4.0.0.alpha0+ Build ID: 620fff54ca9cd04459cc5d963ef94d4438129fe4 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 Fixed by https://gerrit.libreoffice.org/plugins/gitiles/core/+/1aac73a1fb260e4c76a483a68f003913fdd2c4bb @Lásló, Two questions: 1. Should we create a unittest for it? 2. Should it be backported to 6.3 ?