If you turn on recording and showing changes in document find and replace will replace even things already deleted. Example: 1. Create new document. 2. Write "This is a document". 3. Turn on showing and recording changes. 4. Delete the word "document" so you have "This is a". 5. Replace document with "file". 6. The document will contain: "This is a file." instead of "This is a".
PS. In point 5 I mean "Use search and replace to change word 'document' to 'file'". Sorry for being vague.
I tested the bug as described. I can confirm the bug on my system. Furthermore, the bug is even more serious than described: * First problem as described by Tomasz: The replace deleted word is active/undeleted after search&replace. This actually destroys the written text. * Second problem: After hitting "Replace all" a couple of times, it will keep replacing the deleted text with the new text. The dialog never displays "Word not found" and hence does not stop. Due to the reason that data can be actually made unusable/unreadible, I change the importance to high/major. I hope this is okay. System: Ubuntu 10.4./Gnome, LibreOffice 3.3.2 PPA, Intel 32Bit
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
No longer does find & replace work for me. I have deleted LibeOffice & reinstalled & no change. Maybe there is a report that I didn't see about this or maybe only me? I am only a user so not to good & this as this is the first time I have tried to report a problem.
This severe regression is still there in LibreOffice 3.5. I just 'destroyed' a document myself where track changes was activated (and extensively used) and I wanted to search&replace something. Please increase the severity of this bug!
Still a problem in LO 3.6.2.2. In summary: When "Show tracked changes" is active, "Find" will find text that has been deleted with "track changes" activated. "Find & replace" will replace already deleted text. When you do "Find & replace" with activated "track changes", it will replace the same (already deleted) text again and again. "Replace all" works insofar as it replaces each occurance only once. Actually it can be useful if "Find" also searches tracked deletions - after all you use "track changes" to be able to keep deleted text in the document. But I think it's usually not what you want. So you would have to disable "show tracked changes" just to do a "Find". I cannot imagine a situation where you would like already deleted text to be replaced by newly inserted text. It's definitely a bug that LO does not at least move the cursor behind the replaced text when you choose "Replace" in the "Find & replace" dialogue with "track changes" activated. That leads to the same text being replaced again and again.
please somebody tell me which OOo/LO version did not have this bug. i can reproduce it going back to OOo 3.0.1, so doesn't look like a regression.
I can't remember that this has ever worked differently. The corresponding OOo bug was filed in 2007 for OOo 2.3: https://issues.apache.org/ooo/show_bug.cgi?id=82591
Bulk change: Bibisected bugs can be assumed to be regressions.
removing erroneously added "regression", see comment #7
According to comment 7 this isn't a regression, thus remove bibisected35 bibisected35older from whiteboard
** 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.0.5 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: 2015-09-03
This issue is still present in Version: 5.0.1.2 Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: es-ES (es_ES) on Windows 7 (64-bit)
** 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.1.5 or 5.2.1 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 helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Bug still present in Version: 5.1.4.2 Build-ID: 1:5.1.4-0ubuntu1
*** Bug 65056 has been marked as a duplicate of this bug. ***
** 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
This bug still exists in LO 6.0 and is still very annoying. Example: If you work with long documents in a team, track changes is often enabled. If you then, for example, replace the British "ise" / "isation" with "ize" / "ization", then you end up with lots of rubbish in the document. LibreOffice Writer does also replace the string in all deleted words and displays the replaced string as not deleted (!). In other words, everywhere in the document are nonsense "ize" / "ization" strings, which you have to manually clean. -> extremely annoying and time-consuming bug! Version: 6.0.3.2 Build-ID: 1:6.0.3~rc2-0ubuntu0.16.04.1~lo2 CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: gtk2; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
IMHO there are two possible ways to fix this bug: Either: (1) Writer should not find search strings in deleted text at all (meaning text deleted in Track Changes mode) Or: (2) Writer still finds search strings in all text (including deleted text in Track Changes mode) and also replaces them, but replaced text should be flagged as deleted. Solution 1 is preferable to solution 2. However, if solution 2 is easier to implement, IMHO it would be also okay.
The bug is still present in v 6.1.5.2. I don't have the most recent LO release at hand, so please can somebody test this against the newest version? Generally, I hope that this bug receives some attention. In every larger project (with track changes), I encountered issues related to this bug that I had to clean manually. Is a fix so complicated? Version: 6.1.5.2 Build ID: 1:6.1.5-0ubuntu0.18.10.1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3; Locale: en-GB (de_DE.UTF-8); Calc: group threaded
*** Bug 128982 has been marked as a duplicate of this bug. ***
Created attachment 159953 [details] Screenshot of Word and Writer side by side after following the steps Still happens in: Version: 7.0.0.0.alpha0+ (x64) Build ID: 151d95376a13907553032efc271fb0a7a27c9782 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: hu-HU (hu_HU); UI-Language: en-US Calc: CL Also: this behavior is the same as in Word.
I cannot re(In reply to NISZ LibreOffice Team from comment #23) > Created attachment 159953 [details] > Screenshot of Word and Writer side by side after following the steps > > Still happens in: > > Version: 7.0.0.0.alpha0+ (x64) > Build ID: 151d95376a13907553032efc271fb0a7a27c9782 > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: > win; > Locale: hu-HU (hu_HU); UI-Language: en-US > Calc: CL > > Also: this behavior is the same as in Word. I cannot reproduce this issue in Microsoft Word. I have an Office 365 subscription and I only use .docx files.
(In reply to NISZ LibreOffice Team from comment #23) > Created attachment 159953 [details] > Screenshot of Word and Writer side by side after following the steps > > Still happens in: > > Version: 7.0.0.0.alpha0+ (x64) > Build ID: 151d95376a13907553032efc271fb0a7a27c9782 > CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: > win; > Locale: hu-HU (hu_HU); UI-Language: en-US > Calc: CL > > Also: this behavior is the same as in Word. Try replacing document with file a few more times.
Clearly a bug to me, deleted content is still gone even when TC is on (comment 19, option 1). Don't see need for input from UX.
Using LO 7.1.6.2, this is also a problem for me. If show track-changes is on, search-and-replace will find text in deleted text, replace it with NON-DELETED replacement text, and can then start over, replacing it once again. As a result, search-and-replace is effectively unusable when track-changes are shown (something that I as a user can only learn the hard way). IMHO, the importance is higher than the current setting of "normal". Two possible solutions were mentioned in comment 19: (1) Writer should not find search strings in deleted text at all (meaning text deleted in Track Changes mode) Or: (2) Writer still finds search strings in all text (including deleted text in Track Changes mode) and also replaces them, but replaced text should be flagged as deleted. A possible third could be: (3) In search-and-replace mode, deleted text is not found (i.e., option 1 in this case), while in search-only mode, deleted text is found if track-changes are shown (i.e., option 2 in this case). The advantage of option 3 is that it is still possible to search in all the text that is seen on the screen. But I have no problems going for the most simple solution: Option 1. Version: 7.1.6.2 (x64) / LibreOffice Community Build ID: 0e133318fcee89abacd6a7d077e292f1145735c3 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded
reproduced in: Version: 7.3.0.1 / LibreOffice Community Build ID: 840fe2f57ae5ad80d62bfa6e25550cb10ddabd1d CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(In reply to NISZ LibreOffice Team from comment #23) > Created attachment 159953 [details] > Screenshot of Word and Writer side by side after following the steps > > Still happens in: > > Version: 7.0.0.0.alpha0+ (x64) > [...] > > Also: this behavior is the same as in Word. As noted by NISZ LibreOffice Team, the behaviour is very much similar i Word: Also in Word, Search & Replace while showing track-changes, does search within deleted text and replaces with non-deleted text. Just tested with MS Office 365. I can see why it can sometimes be relevant to search also in deleted text, e.g. to find where you (or a colleague) deleted something. And if you do not want this, just turn off showing track-changes. But I fail to see why anybody would want already-deleted text to be part of replacing. (Even before the problems of doing more than one search & replace, leading to several instances of the new text.) Well, failing the see the use could be just my lack of imagination. So: Can anybody come up with a case where searching within deleted text and replacing with new text would be the intended behaviour? Put another way: Can anybody see a reason why this would NOT be a bug (happening to be shared by LO and MS Office)? PS: Word notes the user that "We are through searching the document" after one pass, so the user will at least know that if s/he continues replacing, it will be in text that had already been considered. This will stop most users from repeated replacement, but does not change the question how replacing at all in deleted text could be the intended behaviour.
Please don't spread incorrect information. It does not resemble the Microsoft Word behavior. I just tested on both Sharepoint and desktop MS Office 365. Please test again. You probably did not understand the bug. Libreoffice replaces the deleted text with each recursion while Microsoft Office does not replace deleted text.
(In reply to Hussam Al-Tayeb from comment #30) > Please don't spread incorrect information. > > It does not resemble the Microsoft Word behavior. I just tested on both > Sharepoint and desktop MS Office 365. > Please test again. You probably did not understand the bug. > Libreoffice replaces the deleted text with each recursion while > Microsoft Office does not replace deleted text. Just tested once again with Word from MS Office 365, confirming that a variant of this bug is indeed present in MS Office: Opening some text, deleting with track-changes on and shown, and then using search&replace: the searched text is found also in the deleted text and replaced with non-deleted text. I have reported it to MS Office as a bug. Well, to get back to the point of a LibreOffice forum: The bug is still present in LO 7.3.2.2
*** Bug 147570 has been marked as a duplicate of this bug. ***