Bug 62601 - Quick search (ctrl+f) affected by invisible option from the search-and-replace dialog
Summary: Quick search (ctrl+f) affected by invisible option from the search-and-replac...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: BSA target:4.2.0
Keywords:
: 37179 64635 102512 102781 (view as bug list)
Depends on:
Blocks: Find-Search Find-Toolbar
  Show dependency treegraph
 
Reported: 2013-03-21 17:43 UTC by Eltomito
Modified: 2023-10-13 19:21 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
A screenshot demonstrating the current misbehavior of the quick search box invoked with ctrl+f. (40.96 KB, image/png)
2013-03-21 17:43 UTC, Eltomito
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eltomito 2013-03-21 17:43:42 UTC
Created attachment 76872 [details]
A screenshot demonstrating the current misbehavior of the quick search box invoked with ctrl+f.

Problem description: 

When using the quick search box while editing in Writer (invoked with ctrl+F), the search string is interpreted as a regular expression if the "use regular expressions" option has been checked in the "search and replace" dialog before. However, there is no immediate way to check, uncheck or just check out the state of that option from the quick search dialog.

Steps to reproduce:
0. Type ??? in an empty writer document
1. Open the Search-and-replace dialog (ctrl+h)
2. Check "Use regular expressions"
3. Close the Search-and-replace dialog.
4. Open quick search (ctrl+f)
5. Type "???" in the find box and press enter.

Current behavior:

   No occurrence of the search string is found.

Expected behavior:

   The ??? we typed in the empty document in the beginning are found
   (because there is no "regular expression" option visible, so the user naturally expects the ??? to be interpreted literally and not as special characters).

Operating System: Ubuntu
Version: 4.0.1.2 release
Comment 1 Jorendc 2013-04-05 23:22:38 UTC
Thanks for reporting!

I can reproduce this behavior using Mac OSX 10.8.3 and LibreOffice 4.0.2.2. Therefore I mark this bug as NEW.

I mark this bug as minor, medium.
Minor: does prevent you to use some features
Medium: default priority in the minor range

See https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Thanks for the clear steps!

Kind regards,
Joren
Comment 2 Cor Nouws 2013-05-12 10:19:11 UTC
Hi
thanks for reporting.
AFAICR, this is inherrited behaviour from OOo
There is this related issue
  https://issues.apache.org/ooo/show_bug.cgi?id=88714
So it's a wider area that needs some investigation and where improvement is possible.
Comment 3 To Do 2013-05-18 13:01:21 UTC
This bug affects me too. I confirm it that this is not only a problem with using the "regular expressions" option but also using the "similarity search" option as well.

See this bug: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=64635
Comment 4 Michael Stahl (allotropia) 2013-05-28 18:23:45 UTC
*** Bug 64635 has been marked as a duplicate of this bug. ***
Comment 5 Commit Notification 2013-06-29 17:51:43 UTC
abdulmajeed ahmed committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=df9e6ab514ca1c97c7eb69e169c958619c03d429

fdo#62601 Quick search affected by invisible option from the search&replace



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 6 Cor Nouws 2013-09-03 20:10:24 UTC
(In reply to comment #5)
> abdulmajeed ahmed committed a patch related to this issue.
> It has been pushed to "master":


Thanks a lot - a useful improvement :) !
Comment 7 Kumāra 2013-11-13 05:53:00 UTC
Is this really fixed? As far as I can tell on LO 4.1.2.3, the (ill) behavior remains. It's not just about the "use regular expressions" option. It's about any option made in the "Find & Replace" dialog box, formatting included.

Btw, this looks like a duplicate report of bug 37179.
Comment 8 retired 2013-11-13 11:59:07 UTC
Kumara: from what I see above target is 4.2.
Comment 9 Kumāra 2013-11-15 01:29:21 UTC
*** Bug 37179 has been marked as a duplicate of this bug. ***
Comment 10 Kumāra 2016-09-26 07:50:34 UTC
Actually, even on LO5, this still isn't fixed. Can someone else confirm?
Comment 11 Cor Nouws 2016-09-26 08:42:16 UTC
(In reply to Kumāra from comment #10)
> Actually, even on LO5, this still isn't fixed. Can someone else confirm?
Comment 12 Cor Nouws 2016-09-26 08:42:55 UTC
(In reply to Cor Nouws from comment #11)
> (In reply to Kumāra from comment #10)
> > Actually, even on LO5, this still isn't fixed. Can someone else confirm?

I have mixed results, AFAICS, but will try to understand more details soon
Comment 13 Eltomito 2016-10-12 10:20:17 UTC
Hi! It's me again :)

I tested how it works in LO 5.2.0.4 on Ubuntu 14.04 and it seems pretty sane.

The only thing that's a bit weird is that the "Regular expressions" option seems to work in a different way than any other search option.

If you keep the ctrl+h dialog open and set an option in it, such as "Match case" or "Similarity search", using the simple ctrl+f search box clears these options. However, the "Regular expression" check stays checked even if you use the simple search box but in effect it's ignored. So, the search behavior seems correct to me, it does what I expect, but I'm a bit worried about the internals of how it's done. ;)

But I guess it's just nitpicking...
Comment 14 Cor Nouws 2017-01-01 21:31:10 UTC
*** Bug 102512 has been marked as a duplicate of this bug. ***
Comment 15 Xisco Faulí 2017-10-28 18:26:12 UTC
*** Bug 102781 has been marked as a duplicate of this bug. ***
Comment 16 Eltomito 2018-02-09 18:50:29 UTC
I'm sorry I have to reopen, but this bug is back even though in a slightly altered form. This time, it's the Format from the CTRL+H search dialog that poisons the CTRL+F search field.

* Steps to reproduce:

  1) Write "Hey, dude!" in a document (and don't put any font effects on it).

  2) Open the CTRL+H search dialog
     and in Other options -> Format -> Font Effects,
     set "Effects:" to "Capitals"

  3) Close the search dialog and try to do a CTRL+F search for the string "dude".
     "dude" isn't found.

* Expected result: "dude" should be found.

I'm reopening this bug even though the steps to reproduce and the exact symptoms are different, because I think the underlying cause is the same - insufficient separation of the CTRL+F search and the CTRL+H search.

I found this bug on Ubuntu 16.04 in this build of LO:
Version: 6.0.0.3
Build ID: 1:6.0.0~rc3-0ubuntu0.16.04.1~lo7
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2;
Comment 17 Xisco Faulí 2018-02-12 18:39:48 UTC
Dear Eltomito,
This bug has been in RESOLVED FIXED status for more than 6 months.
If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if     needed, the steps and documents to reproduce it.
Thanks for your understanding and collaboration.
Closing as RESOLVED FIXED