Hide Forgot
Description of problem: The number of saved searches in the Find & Replace dialog does not change from default of 10 when edited. In https://wiki.documentfoundation.org/ReleaseNotes/6.3: The number of saved searches in the Find & Replace dialog can be adjusted per expert configuration Tools ▸ Options ▸ LibreOffice ▸ Advanced org::openoffice::Office::Common::Misc::FindReplaceRememberedSearches tdf#122322 Version-Release number of selected component (if applicable): RHEL-8.1.0-20191015.0 LO 6.3.3.2 How reproducible: 100% I have seen this on F30, as well. Steps to Reproduce: 1. Tools -> Options -> LibreOffice -> Advanced -> Open Expert Configuration button 2. Look for org.openoffice.Office.Common.Misc.FindReplaceRememberedSearches NOTE: org.openoffice.Office.Common is in the first part of the list and you need to open this value and drill down on Misc and the Find value. 3. Double click the value to change it. 4. Change to a different value than the default of 10, click OK and OK, again. 5. Click Apply to save changes 6. Use CTRL-F or the toobar to search for search1, search2, etc. I could start this in Calc and open Writer and see the same results. Actual results: The number of saved searches in the Find & Replace dialog does not change from default of 10 when edited. Expected results: The number of saved searches in the Find & Replace dialog does change from default of 10 when edited to the new number that was saved. Additional info:
This is filed against RHEL-8 and mentions "RHEL-8.1.0-20191015.0 and LO 6.3.3.2", but RHEL-8 only has LibreOffice 6.0.6 currently which doesn't have the feature or configuration element mentioned in the 6.3 release notes. In Fedora 30 if I make the number larger then it seems to do the right thing, but doesn't seem to do the right thing if I *reduce* the number
I have installed LO 6.0 and 6.3 on a RHEL 8.1.0 system. I did see that 6.0 had the functionality missing. I am adding 6.3 test cases to the LO test plan based on the release notes that are public in the original post. I guess I was just trying to get ahead of the testing and finding bugs earlier so that when the RHEL release supports => LO 6.3, this will be a non-issue.
There's definitely something a little whacky about this, looks to me that the wrong candidates are also rotated out of the list when it hits the max
I wasn't sure how it was supposed to show relevant results and glad you caught it.
https://gerrit.libreoffice.org/#/c/83088/ for problem that setting a lower amount to save didn't do anything
I would also look for a higher value, too. When I tested it, I set the # to 20 and could only get 10 and when I went over 10, the first searches were popped off the list.
https://gerrit.libreoffice.org/#/c/83094/ for the issue that the wrong elements are removed when the limit is hit
The fixes are upstream now in upstream master and proposed for upstream 6-3. Also included in F31, which has 6.3 (while F30 has 6.2 which doesn't have the feature). I'm not sure how to proceed with this bug because the feature doesn't exist in RHEL-8 in order to be fixed there. Move this to Fedora 31 ?, or dev-nack it for RHEL ?
Yeah, I will move it to F31.
FEDORA-2019-fb7333e52b has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb7333e52b
libreoffice-6.3.3.2-3.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fb7333e52b
libreoffice-6.3.3.2-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.