Created attachment 194728 [details] Sample Document Steps how to reproducewith Server Installation of Version: 24.8.0.0.alpha0+ (X86_64) Build ID: 2146e66d8df2b7b6a2dd868e886cae76aaf7f48b CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE; Theme: Colibre Calc: threaded – normal Test Profile created from 7.6 1. Open attached Sample document, mace sure that you have free floating find bar 2. <Ctrl-F> (or your locale shortcut) for "Find" » Find Dialog bar opens 3. Type "xxx" into Search String input field and <Enter> » Nothing found as expected Expected: Some Message "not found" Actual: Nothing 😥 Aditional Info: a) No obvious DUPs found with Query <https://bugs.documentfoundation.org/buglist.cgi?bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_severity=enhancement&component=Calc&f1=short_desc&f2=longdesc&f3=days_elapsed&list_id=1743438&longdesc=find%20search&longdesc_type=allwordssubstr&o1=anywordssubstr&o2=anywordssubstr&product=LibreOffice&query_format=advanced&resolution=---&resolution=WONTFIX&short_desc=find%20search&short_desc_type=anywordssubstr&v1=no%20not%20without&v2=no%20not%20without%20vain%20success>
Created attachment 194729 [details] C:\Users\Raine\Videos\Captures Video showing problem: b) Blue higlighted Message "no search results" appears in invisible / hidden area of search bar. c) Suggested solution: no bessage, but string input bar changes to light red highlight background
Reproducible Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2 CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded and Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0e2409e5e3c73ec25c61aa4ea140d114869ea512 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Looks as the floating is too short to show the message, enlarge it, shows the message in a second line.
Still worked fine with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7fff4e2ca6739928f72e5f0d2eb5820823916769 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded So seems that problem appeared somewhere between 24.2.0.0.alpha0+ and 24.8? And this is really annoying!
This seems to have begun at the below commit in bibisect repository/OS linux-64-24.2. Before this commit I have visual sign (red icon on linux GTK3) of "nothing found" in the text area. Adding Cc: to Heiko Tietze ; Could you possibly take a look at this one? Thanks 442e89259ccba9bc108d7157c550e896d304dc73 is the first bad commit commit 442e89259ccba9bc108d7157c550e896d304dc73 Author: Jenkins Build User <tdf@maggie.tdf> Date: Sat Oct 28 11:34:13 2023 +0200 source 97d3d4f371f82704dba907975e6cfdaac456fe4d 156943: Resolves tdf#156227 - More appealing feedback for find/quickfind | https://gerrit.libreoffice.org/c/core/+/156943
Could imagine something in LabelItemWindow::SetOptimalSize() like Size aToolboxSize; vcl::Window* pToolBox = GetParent(); for (Window* pWin = pToolBox->GetWindow(GetWindowType::FirstChild); pWin; pWin = pWin->GetWindow(GetWindowType::Next)) aToolboxSize += pWin->GetSizePixel(); pToolBox->SetOutputSizePixel(aToolboxSize); but that's clumsy and breaks the user customization in terms of sizing the toolbar (which does not work well for me on Linux/Qt). Any advice, Mike?
(In reply to Rainer Bielefeld Retired from comment #1) > c) Suggested solution: no bessage, but string input bar changes to light red > highlight background +1. A side note: attachment 194729 [details] is very nice ;-P
(In reply to Rainer Bielefeld Retired from comment #1) > c) Suggested solution: no bessage, but string input bar changes to light red > highlight background Meaning to revert the patch ignoring bug 156227.
Key here is that the Find bar TB when undocked has a limited width. When docked, the "Search key not found" message is appended to the TB's single line. When floating, the TB expands and the message is wrapped to a second line. When undocked user can expand the height of the TB app frame, but would expect the undocked TB to expand horizontally without the wrap needed to hold the message. There is no reason to revert work on bug 156227, the message/notice is required for a11y.
Patch https://gerrit.libreoffice.org/c/core/+/170167 will give feedback for not_found as well as end/beginning_reached per entry message type in floating mode. But you'll miss some (rarely shown) information anyway.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4e606c5b38139c4424fe9334aed32515c7547418 Resolves tdf#161568 - Feedback for QFS in floating mode It will be available in 25.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 "libreoffice-24-8": https://git.libreoffice.org/core/commit/982c262b479a5326925c13dfb7fb258901c6f348 Resolves tdf#161568 - Feedback for QFS in floating mode It will be available in 24.8.0.2. 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.