Bug Hunting Session
Bug 44861 - EDITING: result 'Find&Replace All' wrong for particular Regular Expression
Summary: EDITING: result 'Find&Replace All' wrong for particular Regular Expression
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high normal
Assignee: David Tardon
URL:
Whiteboard: target:3.6.0 target:3.5.3 target:6.3.0
Keywords:
: 47659 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2012-01-17 05:52 UTC by sasha.libreoffice
Modified: 2019-01-01 15:40 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
document that demonstrates problem with find&replace (12.12 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-01-17 05:52 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2012-01-17 05:52:38 UTC
Created attachment 55673 [details]
document that demonstrates problem with find&replace

to reproduce this problem:
0. Open attachment 
1. Edit->Find&Replace
2. Place into field "Search for":
([0-9]{2})([0-9]{2})
3. Place into field "Replace with":
$1.$2
4. click "More option" on bottom of dialog
5. check option "Enable regular expressions"
6. Press "Replace all"
Expected: instead of 1345-1430 appears 13.45-14.30
Actually: instead of 1345-1430 appears 13.45-14..0
What is interesting: if press "Replace" to replace one-by-one cell, it replaces correctly

reproduced in LibO 3.3.4, 3.4.3 and 3.5.0 beta 2 on Fedora 64 bit and Windows XP 32 bit
Comment 1 Florian Reisinger 2012-01-21 04:02:55 UTC
Confirm with LibO 3.5RC1
One by one:
13.45-14.30
13.45-14.30
14.50-15.30
12.55-13.35
12.30-13.40
In one go:
13.45-13..4
13.45-13..4
14.50-14..5
12.55-12..5
12.30-12..3
Comment 2 sasha.libreoffice 2012-01-23 00:57:27 UTC
@ Florian Reisinger
Thanks for interesting in my bug. But version -- most old version of LibO, where bug is reproducible, in my case 3.3.4. It is not current version of LibO.
Comment 3 Timur 2012-04-09 02:49:29 UTC
*** Bug 47659 has been marked as a duplicate of this bug. ***
Comment 4 Timur 2012-04-09 02:52:09 UTC
I was told that LO doesn't tolerate the character "&" at the beginning of the search or replace string, and the problem was reported in OOo and LO bug https://issues.apache.org/ooo/show_bug.cgi?id=116928. 

As a temporary solution, I recommend Alternative Find & Replace extension.

There are different requests for Find & Replace. I opened Bug 38261 - Better Find&Replace with regular expressions, but it's Enhancement, and thus not a priority.
Comment 5 Cor Nouws 2012-04-15 08:20:21 UTC
(In reply to comment #4)
> I was told that LO doesn't tolerate the character "&" at the beginning of the
> search or replace string, and the problem was reported in OOo and LO bug
> https://issues.apache.org/ooo/show_bug.cgi?id=116928. 

thanks for the info, then this one is an enhancement, so also not an MAB
thanks for the suggestion too:
Comment 6 Ninj 2012-04-15 09:04:35 UTC
Not sure i understand why we speak of enhancement here. This is a bug, obviously, which prevents using "Replace All" with regular expressions. My bug, which was marked as a duplicate for this one (and it looks like, indeed), clearly shows a wrong behaviour which can lead to malicious errors hard to notice when replacing many strings.
Comment 7 Cor Nouws 2012-04-15 10:59:29 UTC
(In reply to comment #6)
> Not sure i understand why we speak of enhancement here. This is a bug,

Maybe I'm wrong - I'll ask the QA list for others to have a look.
Comment 8 dE 2012-04-15 21:07:41 UTC
Very less people using this feature.
Comment 9 sasha.libreoffice 2012-04-16 03:05:46 UTC
Just for be more clear: in original descriptions nothing about "&" character. If problem with it exist, then it is completely another bug.
Comment 10 Patrick Oltmann 2012-04-16 15:15:54 UTC
I can reproduce this issue with LibO 3.5.2.2. For me this is clearly a bug, since it runs contrary to people knowledgable about REs would expect. REs are probably not the feature that everyone needs, but for me it's still an important distinction of LibO versus MS Office... and as long as it is available it should be implemented correctly.

Can't say much about the ampersand (&) issue, since I did not understand why the Apache Bug given should be related. Plus: There is no ampersand in the search or replace string, so most likely this is a different issue.
Comment 11 Timur 2012-04-17 00:08:49 UTC
This is clearly a bug. I changed back to "Severity|normal" and "Priority|high". 
Cor Nouws and dE, please don't change without understanding what this means. 
Regular expressions are important advanced function that can be used either directly either through an add-on which enhances poor LO FInd&Replace dialog.
Comment 12 Don't use this account, use tml@iki.fi 2012-04-17 00:19:43 UTC
Priority wars! Please, do spend you time twiddling that back and forth, it's good and productive.
Comment 13 David Tardon 2012-04-17 22:09:51 UTC
dtardon->dE: "The title clearly says "LibreOffice 3.5 most annoying bugs"... yours is not even a bug. ... We're only interested in bugs which cause data loss, corruption, crashes, and other i/o errors (especially with MS office formats)." So by your standards an incorrect replacement (which may go unnoticed) is not a data loss? Not even a bug?

dtardon grabs some popcorn and eagerly awaits the next round of MAB changes...
Comment 14 David Tardon 2012-04-18 00:48:19 UTC
Allright, let the bug be fixed!
Comment 15 Not Assigned 2012-04-18 00:51:14 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "master":

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

fdo#44861 make "Replace All" work with REs
Comment 16 Rainer Bielefeld Retired 2012-04-18 00:55:31 UTC
Here some comments, most became obsolete with David's fix:

This is inherited from OOo, I see it in OOo 3.3., OOo 3.4Beta and OOo 3.1.1. OOo2 not tested, OOo 1.1.4 did not know the $-replace-reference.

The problem is limited to CALC, I tested the sample document pasted as plain text to a new WRITER document, result 'Replace all' as expected.

I believe CALC has a problem to manage the find results and to associate them with the correct replace actions.

I additionally tested with the complete contents of the 5 cells in the sample document in one Cell A1 of a new spreadsheet:

1. <f2> for edit mode
2. click before very first character
3. Menu 'Edit -> Find and Replace -> insert find and replace strings -> 
   click "Regular Expressions"'
4. <Replace All>
   Expected: all 4-number-groups get an additional dot into the middle
   Actual: see below

Result of step 4:
13.45-13..4
13..4-13..4
13..4-13..4
13..4-13..4
13..4-13..4

Here also everything works fine when I replace one by one.

@All:
I doubt that a bug concerning a function that never worked can be a "MAB". But if my suspect that there is a deeper find and replace problem is true, related problems might justify such a rating (I still doubt and tend to agree with dE's decision). IMHO  careful research is much more relevant for a quick bugfixing process than listing in MAB

@Timur:
I do not understand relation to the AOOo bug
I consider your comments as inappropriate (although I agree tat this is a Bug after my results in WRITER).  

@David:
Thx for stopping discussion here with a FIX :-)
Comment 17 Not Assigned 2012-04-18 02:13:37 UTC
David Tardon committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4bd76b74c0145635ef69caa94e3235f6ce3ab5de&g=libreoffice-3-5

fdo#44861 make "Replace All" work with REs


It will be available in LibreOffice 3.5.3.
Comment 18 sasha.libreoffice 2012-04-18 03:34:30 UTC
@ David Tardon
Thanks for fixing!
Comment 19 Ninj 2012-04-18 03:59:23 UTC
@David Tardon: thank you, a fix is indeed much more efficient than a war! Can't wait for Calc 3.5.3.
Comment 20 Jean-Baptiste Faure 2012-04-18 04:09:21 UTC
Thnak you, works now as expected in LO 3.5.3 rc0+ (LibreOffice 3.5.3rc0+ Version ID : 3d2333d-a73d29c-6845e52-f269e46-cd57e28)

Best regards. JBF
Comment 21 dE 2012-04-18 07:59:31 UTC
Ok, this is how you get a bug fixed REAL quick in libreoffice! :D ;)
Comment 22 sasha.libreoffice 2012-04-18 08:03:59 UTC
@ dE
Now try to replace bugreports in MAB, closed by duplicate by their survived counterparts. It would be very useful job.
Comment 23 Rainer Bielefeld Retired 2012-04-19 01:13:14 UTC
Works great for me with parallel  installation of  Master "LOdev 3.6.0alpha0+  – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 8a78020]" (tinderbox: Win-x86@6-fast pull time 2012-04-18 23:51:20) and proceeding due to original report.

But I can't test due to comment 16 "tested with the complete contents of the 5 cells in the sample document in one Cell A1" (there is a mistake in the description: "A1" should be "B1") because of "Bug 48909 - EDITING: Crash when copy/paste contents of adjanced cells into 1 Cell".

Currently I can't tell with what commit the bug has been introduced.
Comment 24 Commit Notification 2019-01-01 15:40:55 UTC
Zdeněk Crhonek committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/ef58bf56ad292656ad2de0a417eda72cc170f782%5E%21

uitest for bug tdf#44861

It will be available in 6.3.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.