Description: In the provided *Test.ods 'Replace All' replaces many cell styles that weren't searched for. On my system the bug happens very frequently, it's repeatable, and on a very stable/clean installation of windows and LibreOffice. The bug involves a major component that would affect many users who manage Style changes using Find and Replace. Steps to Reproduce: 1. Open '20230701 Find and Replace Style Test.ods' 2. Open the Find and Replace dialog (Ctl+H) Select 'All sheets'; Select 'Cell Styles' (Other options) In 'Find:' select style 'ToBeDeleted'; In 'Replace:' select style 'Header1' Click on 'Find All' and see the Search Results showing "291 results found" ['20230701.1 Screenshot.png' shows how every thing should look at this point] 3. Click on 'Replace All' and see the Search Results showing "291 results found" 4. Click again on 'Find All' and see the Search Results now shows there are yet "284 results found" (there should be zero results after replacing them all) [see '20230701.2 Screenshot.png'] 5. In 'Find:' select style 'Header1' Click on 'Find All' and see the Search Results now shows there are "510 results found" (there should be 291) [see '20230701.3 Screenshot.png'] Actual Results: 'Replace All' replaces many cell styles that are not being searched for, and does not replace many cell styles it was searching for that should have been replaced Expected Results: 'Replace All' should replace 291 cells containing the style 'ToBeDeleted' with the style 'Header1' After 'Replace All' there should be zero cells with style 'ToBeDeleted' and 291 cells with style 'Header1' Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.4.7.2 (x86) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Final Notes It can be seen when playing with the (virgin) *Test.ods that a single 'Replace' replaces the next style occurrence found (and not the currently focused cell that should be replaced). In other words, each single replacement is not for the cell found, but the next occurrence of a cell found with the style to be replaced. The *Test.ods is a copy of a spreadsheet in critical and regular use in my small business: The workaround I had to employ to get past this bug in the test case was to not use 'Replace All' but instead click 'Replace' 291 times. This avoids the corruption of cells not searched for that is introduced if using 'Replace All'. Thank you for your time in looking into this: There's a lot more work to be done with Styles on this spreadsheet, so I hope we can come up with answers.
Created attachment 188149 [details] In the initial bug report I refer to this as *Test.ods *Test.ods contains a style named 'ToBeDeleted' (applied in 291 cells) and another style named 'Header1' (not yet applied to any cells)
Created attachment 188150 [details] This is how Find and Replace s/b configured before 'Replace All'
Created attachment 188151 [details] This shows the Search Results for style 'ToBeDeleted' after 'Replace All' (284 results, there should be zero)
Created attachment 188152 [details] This shows the Search Results for 'Header1' after 'Replace All' (510 results, there should be 291)
Maybe the same issue as in https://bugs.documentfoundation.org/show_bug.cgi?id=144299 Reproducible Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e836e69eb6f2f01a475c5679fb338dda7936643f CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Confirmed/reproducible on slightly older version. Version: 7.2.6.2 (x64) / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Confirmed/reproducible on very old version. Version: 5.4.7.2 Build ID: c838ef25c16710f8838b1faec480ebba495259d0 CPU threads: 6; OS: Windows 5.1; UI render: default; Locale: en-US (en_US); Calc: CL
Dear Jeffrey Alan Klute, 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