Bug 53106

Summary: EDITING: 'Find & Replace' loses selection after 'Find'
Product: LibreOffice Reporter: Metehyi VELLE <doude63>
Component: SpreadsheetAssignee: Markus Mohrhard <markus.mohrhard>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: erack, jmadero.dev, jorendc, LibreOffice, libreoffice, markus.mohrhard, mike.hall, serval2412
Version: 3.5.1 releaseKeywords: regression
Hardware: All   
OS: All   
See Also: https://bugs.freedesktop.org/show_bug.cgi?id=44837
Whiteboard: bibisectrequest target:4.1.0.1 target:4.2.0 target:4.0.5
i915 platform: i915 features:
Attachments: Sample Document

Description Metehyi VELLE 2012-08-03 20:50:35 UTC
LibreOffice 3.5:build-403 
Version ID : 350m1(Build:403)
OpenSuse 11.4 64Bit 


When selecting a column and searching for replacement the first item  is found but replace is not appied and column is deselected.

very annoying
Comment 1 Julien Nabet 2012-08-12 14:07:50 UTC
On pc Debian x86-64, with 3.5.4 Debian package (testing repo), I don't reproduce this problem.

On a column contained 2 times the value I want to replace:
a) If I use "Replace" on the whole column
it unselects the column
it replaces only the first cell with the value
it highlight the cell where there has been the replace

b) If I use "Replace All" on the whole column
it unselects the column
it replaces all the cells with the value
it highlight all the cells where there has been the replace

Could you give try a newer LO version (last one is 3.5.5) and tell us if you reproduce this problem?
Comment 2 Metehyi VELLE 2012-08-13 18:44:39 UTC
Sorry this not exactly what is happening.

I use to select a column , then search in this column for a string , it is a conditional search and I only need replace at some places not replace all . So I first do a search for the string , if the condition apply then i do the replacement and search for the next occurence, so not all occurences of the string should be replaced as in your test.

repeat your steps but do first a search to find the first occurence , then try to replace it and searching for the next.
This is where the bug is .




Cheers
Comment 3 Julien Nabet 2012-08-13 19:35:29 UTC
Ok I understand better. Now I don't know if it's a bug or an enhancement (which would be useful!).

Dev/QA guys: any idea about this?
Comment 4 Metehyi VELLE 2012-08-14 16:32:44 UTC
It is definitely a bug or at least a big change in function . I have been using LibreOffice for years and used to apply search and replaces te way i am describing above.
Comment 5 Metehyi VELLE 2012-08-15 04:20:22 UTC
Just after applying an opensuse update of LibreOffice this bug appeared. I have a lot of work to finish so please corret things .

cheers
Comment 6 Metehyi VELLE 2012-08-21 16:24:47 UTC
Hello
is this bug going to be fixed ? I have a lot of work waiting and thousands of search/replaces on a selected column.


Cheers
Comment 7 Julien Nabet 2012-08-21 16:49:03 UTC
Rainer: What do you think, should it be treated by Kohei, Markus or Eike?
Comment 8 paulchen 2012-12-18 20:09:13 UTC
Tested with LO4.000b1, Windows
Can confirm this bug: exactly as described by M.S. the column is deselected after first "Search" and further search in the whole document finds no case of search string.
Comment 9 Metehyi VELLE 2013-02-03 19:35:21 UTC
Hi

any activity on this bug tracking ?


Thanks
Comment 10 mike.hall 2013-02-03 19:42:20 UTC
Have set 'regression'.

Please don't change the LO version - it should be left at the one where the problem was first noticed - have changed it back.
Comment 11 Metehyi VELLE 2013-02-03 20:23:11 UTC
hi

What does it mean regression , 
I hav not changed anything just typed my message !

sorry if I did it unintentionnally.
Comment 12 mike.hall 2013-02-03 21:03:50 UTC
@Metehyi
Regression means that something that used to work no longer does. It's used to identify bugs that have been caused by changes in a newer version.
Comment 13 Julien Nabet 2013-02-03 21:26:02 UTC
(In reply to comment #11)
> hi
> 
> What does it mean regression , 
> I hav not changed anything just typed my message !
> 
> sorry if I did it unintentionnally.
I don't think Mike answered to your last comment but to Paulchen.

1) About version
You declared this bug with 3.5 but the "version" field was set to "Unspecified" instead of "3.5.0"
Then Paulchen tested the bug on LO4.000b1 and confirmed it on this version and  set the field to 4.0.0.0.beta1. (Perhaps he had just noticed "unspecified" but not your description indicated 3.5.0, I don't know)
Then I suppose Mike noticed your description, set "version field" to 3.5.0 and reminded Paulchen to let first version where this bug appeared (see https://wiki.documentfoundation.org/BugReport_Details#Version)

2) About regression
Mike has already answer but again, you can take a look here: https://wiki.documentfoundation.org/BugReport_Details#Version

So the only slight "mistake" you made is perhaps not having specified "version" field at the beginning.

But don't worry, nobody bites here (at least, never heard about this :-))
Comment 14 Rainer Bielefeld Retired 2013-02-04 06:44:39 UTC
This has nothing to do with column selection, it's a general problem for find & replace in selected ranges.

That never worked in a different way, I can't find any hint that the current way how it works might not be as intended, so this one is an enhancement request.

Without this one fixed it will be impossible to fix "Bug 42410 - Replace & Find Next button" also for "only selection"
Comment 15 Metehyi VELLE 2013-02-04 14:19:21 UTC
(In reply to comment #14)
> This has nothing to do with column selection, it's a general problem for
> find & replace in selected ranges.
> 
> That never worked in a different way, I can't find any hint that the current
> way how it works might not be as intended, so this one is an enhancement
> request.
> 
> Without this one fixed it will be impossible to fix "Bug 42410 - Replace &
> Find Next button" also for "only selection"

Hi Rainer ,
It is definitely a bug or at least a regression. I have been using Open/LibreOffice for years and used to apply conditional searches and replaces on a selected column the way i am describing it above. I have done it 100 thousands times, I am 100% sure.
Comment 16 Metehyi VELLE 2013-02-04 15:16:52 UTC
Hi 

Here is a snapshot of my libreoffice installation http://simplest-image-hosting.net/jpeg-0-libreoffversion.

I had a fresh opensuse 12.2 install a few monthes ago , then I worked daily as I was doing since many years with this find and replace then find next on a selected column in calc. I am 100% sure , then sometime an update for libreoffice was offered on opensuse repo and I did the Update , immediatly after that was this problem to see .

What more infos do you need ?

Cheers,
Comment 17 Metehyi VELLE 2013-02-04 15:47:52 UTC
(In reply to comment #13)
> But don't worry, nobody bites here (at least, never heard about this :-))


I know that nobody bites here , but I am not sure that I am at the right place to submit a bug report here...
I know libreoffice is for free and no warranty etc....

I am looking for an other Office suite so as to continue my daily work because I have the feeling I am not taken seriously here since I have submitted my Bug report on 2012-08-03 and after 6 monthes there is no activity  here and nobody is caring.

Cheers,
Comment 18 Rainer Bielefeld Retired 2013-02-04 16:28:00 UTC
Created attachment 74182 [details]
Sample Document

Steps how to reproduce 'Find & Replace in selected column' how it should work, and how it works with Server Installation of   "LibreOffice 3.4.5 English UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit):
1. Open attached sample document "sample.ods"
2. Click on Row Header "A"
   > First Column "A" becomes selected
3. Menu 'Edit -> Find & Replace'
   > Dialog opens
4. <More Options>, check 'Selection only' if necessary
5. Type "a" into Find Pane and "XXX" into 'Replace by'
6. <Find>
   As expected: Finds "a" in A4, column keeps selected
7. <Find>
   As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected
8. <Replace>
   As expected: replaces "a" in A7 by "XXX" column keeps selected
9. <Find>
   As expected: Finds "a" in A10, column keeps selected
  
and so on

10. Close without saving for a different test.

21. Open attached sample document "sample.ods"
22. Click on Row Header "A"
    > First Column "A" becomes selected
23. Menu 'Edit -> Find & Replace'
    > Dialog opens
24. <More Options>, check 'Selection only' if necessary, all other unchecked!
25. Type "a" into Find Pane and "XXX" into 'Replace by'
26. <Find All>
   As expected: Finds "a" in several cells in column A, all hits will be
    selected, cell cursor around A4
27. <Find>
    As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected
28. <Replace>
   As expected: replaces "a" in A7 by "XXX" column keeps selected
29. <Find><Find><Find>
   As expected: Finds "a" in A14, column keeps selected

And so on

Now the same test steps with "LibO  4.0.0.3 rc   -  GERMAN UI / German Locale  [Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)]"  {tinderbox: @6, pull time 2013-01-31 11:30(?)} on German WIN7 Home Premium (64bit) with User Profile updated from 4.0.0.2

Step 6 Bug
----------
Column A becomes unselected, no more rind steps possible, enxt >Find> will find nothing because no selection

Step 27 Bug
-----------
Hits become unselected, no more <Find> possible

I will check where that started

@Metehyi VELLE:
Your comment let me think that we were talking about different things, may be I misinterpreted.

Your comments were too imprecise, so the danger is big that we (QA) try to find a bug we expect to see and not the bug you saw.I hope my example shows how such a report allows absolutely no interpretation.
Comment 19 Metehyi VELLE 2013-02-04 16:49:38 UTC
(In reply to comment #18)
> Created attachment 74182 [details]
> Sample Document
> 
> Steps how to reproduce 'Find & Replace in selected column' how it should
> work, and how it works with Server Installation of   "LibreOffice 3.4.5
> English UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on
> German WIN7 Home Premium (64bit):
> 1. Open attached sample document "sample.ods"

Ok

> 2. Click on Row Header "A"
>    > First Column "A" becomes selected

OK

> 3. Menu 'Edit -> Find & Replace'
>    > Dialog opens
> 4. <More Options>, check 'Selection only' if necessary


OK

> 5. Type "a" into Find Pane and "XXX" into 'Replace by'

OK


> 6. <Find>
>    As expected: Finds "a" in A4, column keeps selected

No from here my column A is unselected clicking find again tells me LOff has reached end of document without finding anything. Do I want to start from beginning on ?

I click yes and a pop up window tells me search string not found.



> 7. <Find>
>    As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected
> 8. <Replace>
>    As expected: replaces "a" in A7 by "XXX" column keeps selected
> 9. <Find>
>    As expected: Finds "a" in A10, column keeps selected
>   
> and so on
> 
> 10. Close without saving for a different test.
> 
> 21. Open attached sample document "sample.ods"
> 22. Click on Row Header "A"
>     > First Column "A" becomes selected
> 23. Menu 'Edit -> Find & Replace'
>     > Dialog opens
> 24. <More Options>, check 'Selection only' if necessary, all other unchecked!
> 25. Type "a" into Find Pane and "XXX" into 'Replace by'
> 26. <Find All>
>    As expected: Finds "a" in several cells in column A, all hits will be
>     selected, cell cursor around A4
> 27. <Find>
>     As expected: Finds "a" in A7, ignores "a" in B5, column keeps selected
> 28. <Replace>
>    As expected: replaces "a" in A7 by "XXX" column keeps selected
> 29. <Find><Find><Find>
>    As expected: Finds "a" in A14, column keeps selected
> 
> And so on
> 


I have a German UI,

> Now the same test steps with "LibO  4.0.0.3 rc   -  GERMAN UI / German
> Locale  [Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)]"  {tinderbox:
> @6, pull time 2013-01-31 11:30(?)} on German WIN7 Home Premium (64bit) with
> User Profile updated from 4.0.0.2
> 
> Step 6 Bug
> ----------
> Column A becomes unselected, no more rind steps possible, enxt >Find> will
> find nothing because no selection

exactly this is what I am telling you .
I only want to find replace in a column selection , I want to find next item and decide wether or not to replace it then search for next in the same selection in the same column.

> 
> Step 27 Bug
> -----------
> Hits become unselected, no more <Find> possible
> 
> I will check where that started

I think now you got it now .


> 
> @Metehyi VELLE:
> Your comment let me think that we were talking about different things, may
> be I misinterpreted.
> 
> Your comments were too imprecise, so the danger is big that we (QA) try to
> find a bug we expect to see and not the bug you saw.I hope my example shows
> how such a report allows absolutely no interpretation.
Comment 20 Rainer Bielefeld Retired 2013-02-04 16:52:29 UTC
Both Bugs from comment above already [Reproducible] with 
* server installation of "LibreOffice 3.5.7.2 rc German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) 
* Server Installation of "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) 

So it seems problem started with 3.5
Same with Simple Find, selection lost after first hit.

Strange that nobody reported that before ...

And yes, it's a regression.

@Spreadsheet Team:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC)
Comment 21 Metehyi VELLE 2013-02-04 17:06:48 UTC
(In reply to comment #20)

> Strange that nobody reported that before ...
Normal , I know many people in my surrounding who tells me about bugs in LO , usually people switch to another vendor because the don't have time to report a bug...or simply they don't want...or whatever....

Ok I myself am an intensive user of LO in many languages add me to your pre-release testers if you want.


Cheers 
> 
> And yes, it's a regression.
> 
> @Spreadsheet Team:
> Please set Status to ASSIGNED and add yourself to "Assigned To" if you
> accept this Bug or forward the Bug if it's not your turf (and remove others
> in team from CC)
Comment 22 Rainer Bielefeld Retired 2013-02-04 17:09:09 UTC
(In reply to comment #19)
<https://wiki.documentfoundation.org/QA-FAQ#How_to_cite_other_comments>,
please stop this useless citing! A single line "@rainer: Yes, that's the bug I reported" would have been enough.
Comment 23 Rainer Bielefeld Retired 2013-02-04 17:10:30 UTC
Some additional actions for Comment 20 necessary because of Mid air collision.
Comment 24 Jorendc 2013-04-03 22:50:28 UTC
(In reply to comment #18)
> Step 6 Bug
> ----------
> Column A becomes unselected, no more rind steps possible, enxt >Find> will
> find nothing because no selection
> 
> Step 27 Bug
> -----------
> Hits become unselected, no more <Find> possible

I did a bibisect and bumped upon this commit of Kohei http://cgit.freedesktop.org/libreoffice/core/commit/?id=0783e78de2ce265e19b739effbff80c37ee98576

As far I understand the commit message, the reported behavior is done by purpose?

@Kohei: am I right?

Kind regards,
Joren
Comment 25 Kohei Yoshida (inactive) 2013-04-08 15:45:14 UTC
(In reply to comment #24)
> (In reply to comment #18)
> > Step 6 Bug
> > ----------
> > Column A becomes unselected, no more rind steps possible, enxt >Find> will
> > find nothing because no selection
> > 
> > Step 27 Bug
> > -----------
> > Hits become unselected, no more <Find> possible
> 
> I did a bibisect and bumped upon this commit of Kohei
> http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=0783e78de2ce265e19b739effbff80c37ee98576
> 
> As far I understand the commit message, the reported behavior is done by
> purpose?
> 
> @Kohei: am I right?

Nope.  This is a bug.  When doing an individual search or replace, the selection should be retained.  When doing search all or replace all, OTOH, the selection resets to the matching cells only.
Comment 26 Commit Notification 2013-06-07 04:54:19 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d28bb70875e9191ff20b6b5751695f583b73a4f0&h=libreoffice-4-1

only reset marked area when using find/replace all, fdo#53106


It will be available in LibreOffice 4.1.

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 27 Commit Notification 2013-06-07 04:54:37 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

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

only reset marked area when using find/replace all, fdo#53106



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 28 Markus Mohrhard 2013-06-07 05:03:51 UTC
Pending review for 4-0.
Comment 29 Commit Notification 2013-06-07 12:10:57 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=728d6cea85e68a563822b6017707a98085a7058c&h=libreoffice-4-0

only reset marked area when using find/replace all, fdo#53106


It will be available in LibreOffice 4.0.5.

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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.