Bug 36800 - "Find & replace" does not search single cell
Summary: "Find & replace" does not search single cell
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Find-Search
  Show dependency treegraph
 
Reported: 2011-05-03 06:35 UTC by Stephan Zietsman
Modified: 2017-08-09 14:58 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
patch for find and replace bug (510 bytes, patch)
2011-07-31 22:02 UTC, mhst
Details
Test case (7.35 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-01-18 21:58 UTC, Turtle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Zietsman 2011-05-03 06:35:10 UTC
If only one cell is selected, the "Find & replace" dialogue always returns "Search key not found," when doing a simple "find", regardless of whether or not the search key is present in the cell.

 -= To reproduce =-

Open a new spreadsheet (File -> New -> Spreadsheet)
In Cell A1, enter the following text (without quotes): "The quick brown fox jumps over the lazy dog"
Confirm text entry with ENTER

Select Cell A1 (the cell containing the text)
Open the "Find & replace" dialogue (Ctrl+F)

In the "search for" field, enter "quick"
1. Click on "Find"
   The result is: "Search key not found."

2. Click on "Find all"
   The cell is highlighted as expected

3. In the "replace with" field, enter "slow"
   Click on "Replace"
   The result is that the text gets replaced as expected:
   "The slow brown fox jumps over the lazy dog"

 -= End of reproduction =-

When doing a "find all" or "replace" search, the text is found.  When doing a normal "find", the text is not found.  I suspect that the behaviour in (1) was probably done deliberately, but I think it is inconsistent with the behaviour in (2) and (3).

I am running LibreOfficePortable 3.3.2 as downloaded from http://portableapps.com/apps/office/libreoffice_portable
(The "all languages" version)

Running on: Win7 64bit

About:
LibreOffice 3.3.2 
OOO330m19 (Build:202)
tag libreoffice-3.3.2.2
Comment 1 Muthu 2011-05-04 23:01:07 UTC
Adding another condition for reproducing the problem
-> The highlighted cell has to be A1 as well

Candidate for easyhack?

Source: http://opengrok.libreoffice.org/xref/calc/sc/source/ui/view/viewfun2.cxx#1764
(where the error is thrown - most probably the range for search is set wrongly)
Comment 2 Stephan Zietsman 2011-05-09 02:41:51 UTC
(In reply to comment #1)
> Adding another condition for reproducing the problem
> -> The highlighted cell has to be A1 as well

Muthu, I'm not sure what you mean.  In the reproduction instructions it mentions "Select Cell A1 (the cell containing the text)".  That line is mentioned just before "Open the "Find & replace" dialogue (Ctrl+F)".  Did you just miss that, or are you referring to something else?
Comment 3 Cor Nouws 2011-05-13 06:45:46 UTC
(In reply to comment #0)

> Select Cell A1 (the cell containing the text)

when I actually *select* the cell (ctrl-click or shift-click, or increase/decrease selection) the find/replace simply does work.

Can you pls check this?
Thanks,
Cor
Comment 4 Stephan Zietsman 2011-05-16 06:49:20 UTC
> when I actually *select* the cell (ctrl-click or shift-click, or
> increase/decrease selection) the find/replace simply does work.

To clarify what I mean by "select":  I mean simply click on the cell (not ctrl+click or shift+click).  I.e. the cell is surrounded by a thick border but is not "highlighted" with blue.  However, even if the Cell A1 is both selected (thick border) and highlighted (light blue fill) the pop-up occurs as described ("Search key not found").  What version of LibO are you using?

I apologise if my terminology is/was incorrect.

@Muthu
> The highlighted cell has to be A1 as well

I think I now understand what you mean, Muthu.  It seems that when the procedure is performed with another cell, the find function works as expected.  I.e. if all of the references to "Cell A1" in my original post are replaced with, say, "Cell B1", then there is no "Search key not found" pop-up.
Comment 5 Cor Nouws 2011-05-16 07:09:27 UTC
(In reply to comment #4)
> To clarify what I mean by "select":  I mean simply click on the cell (not
> ctrl+click or shift+click).  I.e. the cell is surrounded by a thick border but
> is not "highlighted" with blue.  

OK, then that's a difference with my test.

> However, even if the Cell A1 is both selected
> (thick border) and highlighted (light blue fill) the pop-up occurs as described
> ("Search key not found").  What version of LibO are you using?

same effect in 3.3.2 and 340beta5

> I apologise if my terminology is/was incorrect.

No problem. Also if the terminology might be 'incorrect': if you perform an action that you expect to have a certain result, there at least is a UX issue.

One solution might be that the option "selection only" is grayed out when there is no real selection.
(Which is another usability improvement for the F&R dialogue which - in itself - is a great tool)
Comment 6 Gabor Jenei 2011-07-27 05:20:59 UTC
Actually it does not seem to be a real bug, when you click out of A1 cell it finds the value in A1 well, so only the text shown there might be wrong, but the program's functionality is ok. (at least in versions 3.5 and 3.4)
Comment 7 mhst 2011-07-31 22:02:52 UTC
Created attachment 49770 [details]
patch for find and replace bug

Hi,

I've tried to hack in this bug. I see that when start to search, the nCol is increase (nCol++). If we put away that, the bug seem to be fixed. Not sure about other case. Please check :D

Thanks
mhst
Comment 8 Kohei Yoshida 2011-08-17 16:35:30 UTC
@mhst:

When a range of cells is selected, and the range has multiple matches, hitting the Find button repeatedly should move from one match to the next, and so on.  And your patch unfortunately breaks that use case.  We deliberately skip the current cell for this particular purpose.

So, to fix this, we need to somehow add special case where the selection contains only one cell.

But then, if the current cell contains the match, and you are already looking at the match in the current cell position, why bother using the Find dialog in the first place?  I'm just curious.
Comment 9 Stephan Zietsman 2011-08-18 05:36:38 UTC
> But then, if the current cell contains the match, and you are already looking
> at the match in the current cell position, why bother using the Find dialog in
> the first place?  I'm just curious.

I agree that it's not obvious why you would want to do it, so I will explain my use case:

Let's say Cell A1 contains a fairly large formula/text, which contains the word "quick" about 5 times.  Now I want to change "quick" to "slow" by using find & replace.  In the "Search for" field, I type "quick".  In the "Replace with" field, I type "slow".  Before I press replace, I want to confirm that the correct reference will be replaced (A2 also contains "quick", which I don't want replaced).  If I press "find", it will go to Cell A2.  But if, instead of "find", I pressed "replace", it would replace the "quick" in Cell A1, not Cell A2.

In the case described above, the "find" button behaves differently to the "replace" button.  It is this discrepancy that drew my attention to the "bug".

Sorry if my explanation is difficult to follow.  If it's unclear, let me know.

> So, to fix this, we need to somehow add special case where the selection
> contains only one cell.

Maybe have a look at the code for the "replace" button.  I suspect it handles a single cell better than "find" does.
Comment 10 Björn Michaelsen 2011-12-23 12:07:36 UTC Comment hidden (obsolete)
Comment 11 Björn Michaelsen 2011-12-23 12:57:12 UTC
An EasyHack should have been checked by developers and thus is confirmed regardless of age. Moving back to NEW from NEEDINFO again. Sorry for the hassle.
Comment 12 Michael Meeks 2012-05-08 13:52:57 UTC
any progress here ? :-)
Comment 13 Florian Reisinger 2012-05-18 09:34:20 UTC
Deleted "Easyhack" from summary.
Comment 14 Michael Stahl (allotropia) 2012-07-06 08:54:51 UTC
Comment on attachment 49770 [details]
patch for find and replace bug

according to comment #8 this patch should not be integrated,
setting the "obsolete" flag so it does not turn up in bugzilla queries.
Comment 15 Turtle 2013-04-24 19:41:25 UTC
I have encountered this bug on 4.0.0.2 on x86_64 Gentoo (linux).
Clicking on a single cell should be able to find and replace in the formula within that single cell. 
Thanks
Comment 16 Björn Michaelsen 2013-10-04 18:48:02 UTC
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.

see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Comment 17 Björn Michaelsen 2015-01-15 16:18:50 UTC
Seems to be nontrivial and stalled since 2011, removing EasyHack
Comment 18 QA Administrators 2016-01-17 20:05:30 UTC Comment hidden (obsolete)
Comment 19 Turtle 2016-01-18 21:58:40 UTC
Created attachment 122065 [details]
Test case

Test case
Comment 20 Turtle 2016-01-18 21:59:49 UTC
Bug is still present in
Version: 5.0.3.2
Build ID: Gentoo official package
Locale: en-US (en_US.UTF-8
Comment 21 saurabhkukade 2016-01-21 17:52:48 UTC
i reproduced it. And this will be my first bug to fixed. So i am assigning to myself.
Comment 22 m_a_riosv 2016-11-23 22:18:41 UTC
Although replace works.
Comment 23 Xisco Faulí 2017-07-13 10:56:03 UTC
Setting Assignee back to default. Please assign it back to yourself if you're
still working on this issue
Comment 24 rama 2017-07-31 12:37:32 UTC
hi,
I try to generate this bug in

Version: 6.0.0.0.alpha0+
Build ID: f9509e7da32e3aa8e99c668f9f3f6d1b2c57fcb9
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk3;
Locale: en_US (en_US.UTF-8); Calc: group

But its not present in this version.

Thank you.
Comment 25 Cor Nouws 2017-08-09 14:57:51 UTC
if the text is present in the single selected cell, the dialog shows "reached end of the document"
if the text is not present, the dialog shows "not found"
 > resolved
Comment 26 Cor Nouws 2017-08-09 14:58:03 UTC
Version: 6.0.0.0.alpha0+
Build ID: 5ad8376d1698026ccab0634605fdb17ea3c59f3a
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: nl-NL (nl_NL.UTF-8); Calc: group