I was astonished when I tried searching in one document ("Doc B") for text I was pretty sure was there, the quick-search wasn't finding any text I tried. I discovered it was because in another document ("Doc A"), I was doing a Find&Replace for a Format (Times New Roman 10.5pt). That should be a per-document setting, not applied to every open document! After opening the F&R panel in the current document ("Doc B") and selecting "No Format", all the searches then succeeded. Perhaps the bug is stranger than I think, though: when I went back to the document where I'm searching for 10.5pt Times New Roman ("Doc A"), expecting that turning off searching by format in Doc B would have turned it off in Doc A - it hadn't! Could the last settings for a F&R in some document be inherited as the initial settings in the next opened document? That's also bad: the F&R should start off from a standard default setting. Although I can see that there would be *some* use cases where the current surprising behaviour would be useful.
It's more complex than that> Sometimes setting the F&R options in one document *does* set the same option for F&R in another. It's quite irritating when you're working on two or more documents at the same time, and doing different kinds of searches repeatedly in each. (In my case, I'm doing complex comparisons, in long documents, guided to the appropriate places by appropriate searches.)
I should probably give an example of the more compex behaviour. I'm searching for text by format in Doc B (to repair errors caused by copying the entire body of Doc A and changing body text style: Ref: https://bugs.documentfoundation.org/show_bug.cgi?id=99014 ). So in Doc B I'm searching for Times New Roman 14. Occasionally I find something questionable,. so I need to find the corresponding point in Doc A. To do that I search for an appropriate unique few words. The search fails: I see that F&R in Doc A has switched to search for Format (again). I click No Format, redo the search, and find the correct point. Switching back to F&R in Doc B, I find its F&R panel now contains the matching text found in Doc A (!), although it is still searching for the desired format (TNR 14pt). So I wipe out the matched text in the F&R panel I'm using in Doc B, and continue my search. In case it's relevant, I have Complex Text Layout turned on in Language Settings->Languages. (This is to enable the use of a non-breaking no-width space to prevent mis-formatting of .44 caliber as . <new line> calibre.)
Repro. Win 7 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: b0e678c86136ef6d65cea66168a99217664c0278 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-04-11_23:06:28 Locale: fi-FI (fi_FI)
** 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
Dear Luke Kendall, 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
Dear Luke Kendall, 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
Bug is as bad as ever, perhaps worse. Now when switching between documents and using F&R panel, I had: 1) The search text copied from one F&R panel into the other. (IMO, a bug) 2) The search by Format was turned on in a second already-open doc with F&R open, after using F&R and turning on a search by Format in the first. 2.1) On one occasion, the search by Bold format in the 1st did NOT change the format being searched for in the 2nd (Regular) 2.2) On another occasion, searching for some bold text in the 1st doc DID change the format being searched for in the 2nd (bold), but then the bold text was not found, when previously it had been. I would suspect an interaction with direct formatting, except the behaviour (2.1 vs 2.2 in the examples above) varied between the same documents I had open without any editing, just by changing what I was searching for in the F&R panels. Version: 7.2.3.2 / LibreOffice Community Build ID: d166454616c1632304285822f9c83ce2e660fd92 CPU threads: 8; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded