Bug 129629 - Find and Replace dialog: "Other options" won't stay closed, if certain options are ticked
Summary: Find and Replace dialog: "Other options" won't stay closed, if certain option...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium minor
Assignee: Justin L
URL:
Whiteboard: target:7.4.0
Keywords: bibisected, bisected, regression
: 140009 (view as bug list)
Depends on:
Blocks: Dialog-Remember-Settings Find&Replace-Dialog
  Show dependency treegraph
 
Reported: 2019-12-26 13:12 UTC by R. Green
Modified: 2022-05-09 17:30 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description R. Green 2019-12-26 13:12:29 UTC
Any writer file will do as an example.

1. Open the Find and Replace dialogue.
2. Click the "Other options" button to close the bottom half of the dialogue.
3. Enter a search term and click "Find next".

Expected result: The selected search term is highlighted in the text, if available. BUT, "Other options" remains closed.
Actual result: "Other options" automatically opens again when the search term is highlighted in the text.

The state of "Other options" should remain as set by the USER.
Comment 1 ian 2019-12-26 21:34:47 UTC
Thank you for reporting the bug. I can confirm that the bug is present in 

Version: 6.5.0.0.alpha0+ (x64)
Build ID: 209fc9fd7fa433947af0bf86e210d73fa7f5a045
CPU threads: 2; OS: Windows 10.0 Build 17763; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 2 Buovjaga 2020-01-24 13:22:04 UTC
This is the result of bug 98544 being fixed. It might be that the fix has to be implemented in a completely different way to avoid this new issue.

Let's alert UX team.
Comment 3 Buovjaga 2020-01-24 13:22:54 UTC
I forgot to mention that I bibisected this with win32-6.1.
Comment 4 Heiko Tietze 2020-02-05 14:12:27 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2020-02-07 10:36:34 UTC
(In reply to Heiko Tietze from comment #4)
> Whether the advanced options are expanded or not depends on what you did
> before. The default is collapsed. And when you manually close it, why should
> it open on any interaction? 
> 
> Sounds like a WFM to me.

Heiko: your statement "And when you manually close it, why should it open on any interaction?" seems to agree with the original reporter, so I am not sure why you propose WFM?

The user problem is exactly that the damned dialog will not stay still. You manually collapse it, hit Find next and it expands.
Comment 6 R. Green 2020-02-17 12:17:10 UTC
(In reply to Heiko Tietze from comment #4)
> And when you manually close it, why should it open on any interaction? 
That's the whole point. It DOES open: every time you perform a "Find next" operation or close and reopen the dialogue. So DWFM (Doesn't work for me). :)

Also, it's not trivial, minor at least.
Comment 7 Heiko Tietze 2020-02-19 10:09:56 UTC
Okay, so let's enhance the "if (IsOptionSet) then DoExpand" to "if (IsOptionSet && !UserCollapsed) then DoExpand". Wouldn't call this a regression.
Comment 8 Timur 2021-02-24 07:43:12 UTC
This is regression, annoying for those with small screen, so not enhancement but bug. I guess it's not Writer but framework, so I'll duplicate Calc report bug 140009.
Comment 9 Timur 2021-02-24 07:46:51 UTC
*** Bug 140009 has been marked as a duplicate of this bug. ***
Comment 10 Timur 2021-03-12 17:08:01 UTC
*** Bug 140972 has been marked as a duplicate of this bug. ***
Comment 11 Justin L 2021-12-02 11:58:22 UTC
Repro 7.4+

Only the FIRST time you do a find-next does the macro area expand. If you change the search term, it will again expand.

I think it is reasonable for it to expand on the START of each time dialog is opened (although the people who are annoyed by this will probably disagree, and request it at least be remembered while the application is open). But certainly once it has opened, then it should remember the user's choice.
Comment 12 Justin L 2021-12-02 12:45:47 UTC
(In reply to Justin L from comment #11)
> I think it is reasonable for it to expand on each dialog start
Proposed fix doing that is http://gerrit.libreoffice.org/c/core/+/126226
Comment 13 Commit Notification 2021-12-03 15:30:36 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3c10bb151e5864c0ff532910b9f81185aa49c21f

tdf#129629 sw UI: Find/replace - stop popping open MORE section

It will be available in 7.4.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 14 Justin L 2021-12-03 15:34:30 UTC
I'm going to mark this as fixed, but feel free to re-open if you test this and feel that it needs to remember the user's choice across multiple uses of the dialog.  (That's what bug 140972 seems to be specifically requesting, for example.)
Comment 15 Commit Notification 2022-04-01 14:43:48 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/93c1241eec9f5df84a96c57f8050efd4851cb0df

tdf#129629: sc: Add UItest

It will be available in 7.4.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 16 Timur 2022-05-09 11:40:18 UTC
I'll set this one to Verified and reopen bug 140972 .