Description: In recent editions of LO, when using the Find function and the Find either does not find the item searched for, the background of the Find field turns red. That is the most annoying feature I have ever experienced in LO, and one of the most annoying features I have ever experienced in any software. The red shading virtually makes the text in the field illegible...the whole thing is just annoying. Can we please go back to no shading or changing the background color automatically in the Find box? I'm sure it sounded useful at the time, but it's a major irritant. Steps to Reproduce: 1. In Writer, invoke the Find function. 2. Type in work or phrase to search foe. 3. If the word or phrase is not found, the background of the Find field automatically turns red. Actual Results: If a word or phrase is not found, the background of the Find field automatically turns red. Expected Results: Expect to get a message below the Find field that word or phrase was not found. Reproducible: Always User Profile Reset: No Additional Info: Invoke a message below the Find field that word or phrase was not found, instead of automatically changing the background color of the Find box to red.
already addressed for LO 7.6.0 release for bug 153933 https://gerrit.libreoffice.org/c/core/+/148348 *** This bug has been marked as a duplicate of bug 153933 ***
Well, patch for bug 153933 makes the warning/error color less obtrusive. But missing results are still indicated via highlighting (and additionally a label). It was introduced for bug 106723 and besides saving space it benefits accessibility. I don't agree with the (slightly exaggerated) "most annoying features I have ever experienced in any software". A possible solution is to allow changing the colors for EntryMessageType Warning and Error- but this consequently affects all controls, the red highlight is also used in the search dialog, for example.
If I am reading the current Status correctly, (RESOLVED, WON'T FIX), this is a disappointing resolution. Please say it isn't the final solution. Why the pushback on dropping what seems to be a feature that the vast majority of users probably don't want (my guestimation)? There is substantial discussion regarding the color of the background, what color it should be, whether to offer users an option, etc., whether it is an actual irritant, etc. The simple and only acceptable solution (in my opinion) is to ditch the background color and return it to its previous state (described by jim_away), which is a line of text UNDER the Find box that turns red when no match is found. It does not matter how you tweak the background shades and the font color, this is simply an undesirable and highly irritating feature, and one that I would dare say, few if any actual end-users wanted. Besides, colors don't render the same on every display and in every OS, which means this will forever be an irritant to many end-users. So what is the point in the change to the colored bg, other than change just for the sake of change? "EVERY IMPROVEMENT REQUIRES A CHANGE, BUT NOT EVERY CHANGE IS AN IMPROVEMENT."
(In reply to larrybradley from comment #3) > The simple and only acceptable solution (in my opinion) is to ditch > the background color and return it to its previous state (described by jim_away), > which is a line of text UNDER the Find box that turns red when no match is found. But this is about the F&R dialog not the quickfind toolbar, right? We could do the same for the quickfind bar and have the font for "No results" in red. All with the argument that a missing result is not an error.
That there is a background color that shows the user that there are no results is a good solution because any information at other places were not seen by the user (seen by colleagues around me in the office) AND there is no space in the UI, especially not directly below or right of the text field.
(In reply to Thomas Lendo from comment #5) > AND there is no space in the UI... We show the label "Search key not found" in addition to the input field highlight, both in the quickfind bar and the F&R dialog. This label could be made red.
I don't see a background color change when a find fails with the F&R dialog. Am I missing something? Can someone post a screenshot of what the problem is, as it stands now?
We discussed the topic in the design meeting. While the highlighting gives very clear feedback it also feels a bit erroneous. So let's keep it plain and show the "Search key not found" label in bold and red. Furthermore we should consider a11y for bug 117173 and show a message box, ideally with a checkbox "[x] Show this dialog" and perhaps depending on the a11y settings. I suggest to handle this in the other ticket.
Created attachment 188588 [details] Screenshot of red background in Firefox search bar
(In reply to Heiko Tietze from comment #8) > Furthermore we should consider a11y for bug 117173 and show a message box, > ideally with a checkbox "[x] Show this dialog" and perhaps depending on the > a11y settings. I suggest to handle this in the other ticket. See my comment in bug 117173 comment 25: If this is just about changing colors (and leaving labels etc. otherwise as they are), this should not affect announcement by screen readers (which bug 117173) is about at all. But still, it's for sure a good idea to ensure proper visibility and contrast in some way. (*If* something is considered necessary in addition to what's planned to be implemented, I'd rather suggest making the background configurable, but ideally, the default solution would IMHO be visible enough already.) With that being said, in Debian testing, my Firefox search bar also uses a red background when nothing is found, s. attachment 188588 [details]. As do Gedit (quite a bright red) and Kate (very light red), so I probably misunderstand something in this bug report or there are more applications doing something similar. (I'd generally be in favour of trying to have a consistent UX across applications where it makes sense.)
I seem to agree with Michael here, and think: 1) There should be an text-based indicator (instead of only color), for reasons of clarity and accessibility, but this should not be an either/or. 2) The change of background color can be helpful because one can rest the eye on the search field. 3) The method of a background change is used in other applications as well – using the same standard makes sense. 4) One should ensure that the contrast is still high enough (which I think a rather light red does) Label in bold and red does not do 2) and 3) and often is visually noisy. If, I would just use a plain text label.
We do show a text in addition to the highlighting. The red background means an error and using it as indicator for zero results is an abuse. The colors are defined per weld::EntryMessageType and drawn using Light Yellow 1 0xffff38 resp. Light Red 1 0xff3838 [1], see also bug 153933. [1] https://opengrok.libreoffice.org/xref/core/vcl/source/app/salvtables.cxx?r=926c5246#3446
*** Bug 157208 has been marked as a duplicate of this bug. ***
How do I withdraw this request? LO is so far superior to Word that it's really not worth everyone's time and trouble for this rather cosmetic issue. My apologies for submitting it to begin with. I'll try to do better and not fret over relatively minor inconveniences. Thanks to all who bring us LO. You do great work.
(In reply to larrybradley from comment #14) > How do I withdraw this request? By setting the status to resolved/wontfix or invalid. But take a look at the duplicate how badly it works in other configurations. Even small changes improve usability, and your suggestion was accepted. Maybe you want to hack it yourself? It's not too difficult...
Created attachment 189608 [details] Screenshot after the patch My proposal for the feedback following the infobar design. Patch at https://gerrit.libreoffice.org/c/core/+/156943
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/97d3d4f371f82704dba907975e6cfdaac456fe4d Resolves tdf#156227 - More appealing feedback for find/quickfind It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5a622f1a29d249a512cc24f99d189f748623c678 Related tdf#156227 - Find/quickfind design It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.