Description: Using Find resets 'Other options' in Find&Replace to default values. Steps to Reproduce: 1. Open Find&Replace (^H) 2. Click on 'Other options' 3. Change an option, e.g. set 'Search in' to 'values'. From now on Find&Replace will search in values in this and all subsequent searches even after Find&Replace dialogue is closed and reopened. 4. Perform a search using plain Find (^F) Actual Results: Open Find&Replace->Other options: values are reset to defaults, 'Search in' is set to 'Formulae' Expected Results: Find should not reset 'Other options' in Find&Replace. Also, optionally: 1. Find should use these 'Other options' when searching 2. 'Other options' should be accessible from the Find dialogue/toolbar Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:57.0) Gecko/20100101 Firefox/57.0 SeaMonkey/2.54a1
Hello, Thanks for reporting this bug. It looks like a duplicate of bug 98544 *** This bug has been marked as a duplicate of bug 98544 ***
Bug 98544 is about keeping 'Other options' section expanded if anything was changed there - makes sense, but is not related to this bug. This bug is about Find resetting 'Other options' in Find&Replace to default values.
I can reproduce that a search with the Find toolbar sets "Other options" in the Find & Replace dialog back to default. As the Find toolbar only searches like Find & Replace with default values, that should not change any settings in the Find & Replace dialog. For me that's a bug. But I call the UX team, maybe there are some deeper insights necessary to understand this behavior. Tested with Version: 6.0.0.0.alpha0+ Build-ID: fc674ad1b795d74a50cb792368ce7eaee74ca904 CPU-Threads: 4; Betriebssystem:Linux 4.10; UI-Render: Standard; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-09-09_00:34:37 Gebietsschema: de-DE (de_DE.UTF-8); Calc: group Tested also with LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4 There, "Regular expressions" and "Similarity search" sometimes is not set back. Haven't found a schema when it will be set back and when not.
(In reply to Thomas Lendo from comment #3) > As the Find toolbar only searches like Find & Replace with default values, > that should not change any settings in the Find & Replace dialog. Yes i would expect the find toolbar not to change the saved settings of the find dialog. Heiko, Stuart, Cor: What is your take on this?
Clearly a bug, user settings have to be persistent.
now it becomes interesting... see bug 62601, complaining that Quick search (ctrl+f) is affected by invisible option from the search-and-replace dialog
(In reply to Cor Nouws from comment #6) > now it becomes interesting... see bug 62601, complaining that Quick search > (ctrl+f) is affected by invisible option from the search-and-replace dialog Thanks, Cor. Is it likely that this bug is a result of fixing that bug in a way that it shouldn't have been fixed?
(In reply to Cor Nouws from comment #6) > now it becomes interesting... see bug 62601, complaining that Quick search > (ctrl+f) is affected by invisible option from the search-and-replace dialog And also bug 102506 about adding other options to plain find - personally I'd vote for this approach. Actually I believe that's how it was originally when find was a dialogue just like F&R until some bright and eager mind decided to turn it into a half-baked toolbar.
(In reply to lvm from comment #8) > Actually I believe that's how it was originally > when find was a dialogue just like F&R until some bright and eager mind > decided to turn it into a half-baked toolbar. Nope. From the time of OOo, there was always a find toolbar, though pressing ctrl+f brought up the dialog, and it always reset stuff in the f&r dialog.
** 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
reproducible in 6.1.2.1 linux-32
Dear lvm, 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 reproducible in Version: 7.2.5.2 / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded
Still reproducible, still didn't fix itself.