Bug 162580 - When upgrading from Find toolbar (Ctrl+F) search to advanced Find and Replace (Ctrl+H) search dialog, inherit (pre-fill) search field's term from current value of find bar's focused search entry
Summary: When upgrading from Find toolbar (Ctrl+F) search to advanced Find and Replace...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
24.8.0.3 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:25.2.0
Keywords: needsDevEval
Depends on:
Blocks: Find-Search Find-Toolbar Dialog-Remember-Settings Find&Replace-Dialog
  Show dependency tree / graph
 
Reported: 2024-08-23 03:13 UTC by Jeff Fortin Tam
Modified: 2024-11-27 05:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Demonstration video (1.05 MB, video/mp4)
2024-08-23 03:37 UTC, Jeff Fortin Tam 		Details
demo of Writer quick find panel implemention of request (257.32 KB, video/x-matroska)
2024-08-25 22:55 UTC, Jim Raykowski 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Fortin Tam 2024-08-23 03:13:24 UTC 
## Problem statement

I often start searching through a spreadsheet with Ctrl+F, and most of the time I cannot find anything because "Sorry Mario, the princess is in another castle, er, sheet."

As it was decided that LibreOffice would not allow searching all sheets directly from the search toolbar (in bug #98270), I then have to "upgrade" my search to use the search-and-replace dialog (Ctrl+H), except that LibreOffice makes me waste my time re-typing my search query again.


## Proposed solution

Instead, when calling the "Find and Replace" dialog from the find toolbar, either by hitting Ctrl+H or by clicking the magnifying glass icon button at the end of that toolbar, then the search dialog should be pre-filled with my existing search query from the find bar, in the same selection state as the find bar's searchentry was.

---

P.s. / related: especially in a workflow where you are forcing me to "upgrade/escalate the search", please consider also remembering the "Search all sheets" setting's state (bug #58676) to save me some extra hoops jumping (related article: https://zachholman.com/posts/shit-work/ …)
Comment 1 Jeff Fortin Tam 2024-08-23 03:37:23 UTC 
Created attachment 195973 [details]
Demonstration video

Clarification: this is currently partially implemented, but not "always".

It only works by pre-filling with the last search query that you typed "Enter" for (i.e. a launched and failed search query). It does not pre-fill with whatever you have currently typed (or corrected) in the Find bar's searchentry if you did not press Enter first.

This attached video demonstration makes the issue clearer.

---

Tested with:

Version: 24.8.0.3 (X86_64) / LibreOffice Community
Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583
CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded
Comment 2 V Stuart Foote 2024-08-23 11:28:42 UTC 
Hmm... can see some utility of allowing the search string to cross bounds--but *not* at the expense of again cross-contaminating the search configuration between the Find Toolbar and the Find and Replace (F&R) dialog. Still have bug 112270 to fully resolve.

@Jim, what do you think. Could the exact use case of pre-populating F&R 'Find' field on opening the dialog with the typed entry (i.e. without executing the search) made from the Find Toolbar entered search text be done reliably?
Comment 3 Jim Raykowski 2024-08-25 22:55:58 UTC 
Created attachment 196015 [details]
demo of Writer quick find panel implemention of request

I was able to make the Writer quick find panel Find and Replace button click behavior as such. Doing this for the find bar Find and Replace button seem not an easy hack.

https://gerrit.libreoffice.org/c/core/+/172375
Comment 4 V Stuart Foote 2024-08-26 01:51:22 UTC 
(In reply to Jim Raykowski from comment #3)

> Created attachment 196015 [details]
> demo of Writer quick find panel implemention of request
> 
> I was able to make the Writer quick find panel Find and Replace button click
> behavior as such. 

Cool! Thanks Jim

> Doing this for the find bar Find and Replace button seem
> not an easy hack.
> 

Goes that way sometimes, thanks for looking. Assume no better for passing string from FB --> F&R dialog using <Ctrl>+H shortcut launch instead of the FB button?

> https://gerrit.libreoffice.org/c/core/+/172375
Comment 5 Commit Notification 2024-09-02 17:45:17 UTC 
Jim Raykowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/9f79c01035fb5851bcba1f8fc646437be84f7194

Related: tdf#162580 When upgrading from Find toolbar search to

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.
Comment 6 BogdanB 2024-11-26 18:03:29 UTC 
Jim, is this bug solved?

I tested on master and if I search for "test" with Ctrl+F, then Ctrl+H the term is moved in to "Find" field. So, seems ok for me.

Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 662c6a6d70bab6b1a6ae8048457907be97f447ca
CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 7 Jim Raykowski 2024-11-27 04:01:19 UTC 
(In reply to BogdanB from comment #6)
> Jim, is this bug solved?
> 
> I tested on master and if I search for "test" with Ctrl+F, then Ctrl+H the
> term is moved in to "Find" field. So, seems ok for me.
> 
> Version: 25.2.0.0.alpha1+ (X86_64) / LibreOffice Community
> Build ID: 662c6a6d70bab6b1a6ae8048457907be97f447ca
> CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: gtk3
> Locale: ro-RO (ro_RO.UTF-8); UI: en-US
> Calc: threaded

For the Ctrl+F find bar I still repro the behavior described in comment 2 and shown in the bug demonstration video.

Possibly you missed to not do a search on the entered term before hitting Ctrl+H.

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 8d114edc1fe479edee486c3818dd458636ce33d3
CPU threads: 4; OS: Windows 11 X86_64 (10.0 build 22631); UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 8 BogdanB 2024-11-27 05:00:30 UTC 
> Possibly you missed to not do a search on the entered term before hitting
> Ctrl+H.
> 
Jeff mentioned "most of the time I cannot find anything because "Sorry Mario, the princess is in another castle, er, sheet.", so I thought is about searching before. Indeed, it is not working for a not searched term.

Can we mark the bug as New based on the fact that it is somehow confirmed?