(OS is Windows 7 Home 32-bit) 1. Create table with repetitious text 2. Select table 3. Open Find & Replace dialog, click Replace (i.e. only the first instance of that string) The new string will be selected, overwriting the original selection and making further replacements within it impossible until the Within Selection box is unticked. Easily remedied but counter-intuitive, and had me stumped for a little while as I tried to figure out why I could only make one replacement.
Version: 4.5.0.0.alpha0+ Build ID: b024e36ddb3b53163d7a01f6f7b5aadb7a858cd9 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-31_09:12:20 When I click "Replace" one more time, then checkbox "Within Selection " is unticked and I can replace text.
Same result as raal. So the question is, should the checkbox be unticked immediately after the first "Replace"? Win 7 Pro 64-bit, Version: 4.4.2.2 Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Locale: fi_FI
Hi (In reply to Beluga from comment #2) > Same result as raal. +1 (windows 7/64 & Version: 4.4.3.2 - 5.0.0.0.beta1) >So the question is, should the checkbox be unticked >immediately after the first "Replace"? In Calc the original selection is kept *and* the checkbox remains unchecked. But the difference is that the search result is indicated by the cell selection. In Writer (for we must broaden the issue to a text selection, not just table cells) would require that the search result is highlighted differently in the selection. Regards Pierre-Yves
This bug does not need to be within a table. I'm on LO 5.1.2 and the original selection is lost as soon as a search is performed, whether it is a Find Once search or a Replace All search. Further manipulation becomes impossible without reselecting the original range again. This is a major weakness to the find/replace function.
There appear to be different usage cases of Find & Replace not all of which are accommodated by the current design. The one I'd like to see made easier is when selecting an area in which several Find & Replaces are to be done. In the current version (5.1.5.2), after the first F&R, the original selection is deselected meaning that the user must re-select the text and then F&R the next text. In that case, I would like the original text to remain selected and the "Current selection only" checkbox to remain checked so I can move back and forth between the "Search For" and "Replace With" edit boxes followed by the "Replace" or "Replace All" buttons. Perhaps we need another checkbox under "Other options" for "Retain current selection" which is visible only if "Current selection only" is checked.
(In reply to Bob Smith from comment #5) > Perhaps we need another checkbox under "Other options" for "Retain current > selection" which is visible only if "Current selection only" is checked. Please no more checkboxes for simple tasks. But the question is valid.
*** Bug 95117 has been marked as a duplicate of this bug. ***
Find & Replace must not change the current selection and should work within the defined boundaries, removing needsUX. It's an annoying bug, affecting all users, and potentially dangerous. Setting importance to high.
Dear tholral, 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
I just tested it and I think the bug is NO MORE in this version replacing and finding works within a table. Version: 7.1.0.3 / LibreOffice Community Build ID: 10(Build:3) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Hi Still reproduced on Windows & Version: 7.1.1.1 (x64) / LibreOffice Community Build ID: 575c5867c4cc13d7ae78f9ce39a54a52ed38c769 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded Regards
Reproducable in LO 7.4.2.3 under LXLE (x64) distro Focal release.Find and replace works only for current selection of text in a table. Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 1; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.4.2~rc3-0ubuntu0.20.04.1~lo1 Calc: threaded
Dear tholral, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still broken in 24.8.2.1.