Apache OpenOffice (AOO) Bugzilla – Issue 112701
Replace selection without previous Find -> incorrect replacement leads to Undo Crash
Last modified: 2017-05-20 10:45:16 UTC
This is one of my best bug finds I think. At least three error in series with option of crash! Steps: 1) File - New - Text Document 2) Write following paragraphs ww qq ww 3) CTRL+A (select all) 4) Edit - Find & Replace 5) Search for: qq 6) Check that only "Current selection only" is marked 7) Press Replace-button I) Here I observe the first error: text in upper paragraph (ww) disappear. 8) Close dialog with Close-button. 9) Move cursor over Undo-button in Standard bar: I see text Undo:Replace:'Ww'->'' Nothing wrong here: automation is changed first letter to big one. 10) Press Undo-button. II) Here I observe the second error: crash (but not always) or disapperence of second text paragraph (qq) or rest of text, only Ww is left. 11) Start program again. There may be bug reporting etc. III) When document is opened I see third bug: text Ww is left and others is gone. I don't know if it is something do to with fact that qq is whole text content of second paragraph? Regard Risto
MRU->TL: insert three paragraphs like described "ww qq ww", select all, open Find&Replace dialog, enter qq to be searched for, click "Replace" -> first paragraph will be replaced and Undo will lead to crash.
Put myself on c/c.
Created attachment 77557 [details] patch for i112701
(In reply to comment #0) I do confirm that and one more issue: After step 7, if you click the Redo buttom, all the text disapears.
Created attachment 77561 [details] Same patch with style changes The patch looks good, however I made some style changes: 1) We try to avoid hardcoding where the patch starts/ends, this can be handled by subversion. 2) We usually add email addresses only in the SVN log with a description of the code and the date. 3) Try to avoid very long lines so that you don't have to scroll all the screen to read the patch. 4) Have subversion prepare the patches for you. I used svn diff main/sw/source/ui/uiview/viewsrch.cxx > patch-i112701 But thanks, the patch looks good! I would like someone else to test this patch.
I am volunteering to have also a look at the provided patch.
@bo.tian: Can you explain the root cause of the bug and how you fixed it?
@Andre: Try this, then it will be easy to understand what happened 1) File - New - Text Document 2) Write following paragraphs ww qq ww 3) Edit - Find & Replace 4) Search for: qq 5) Press Replace-button the first time you press Replace-button , it will search . "qq" will be selected as the result. the second time you press Replace-button "qq" will be replaced it's normal if you have selected something before press Replace-button(description of Risto Jääskeläinen) the first time you press Replace-button, the first line of the selected area will be replaced. it's abnormal . The selected area is seen as the search result of the first press. And then after your first press, it will directly do something the second press should do--Replace. So the bug happened. All I do is to check whether the selected area is the search result before replace happened.
at least I am fulfilling my promise to review the patch.
Comment on attachment 77561 [details] Same patch with style changes Pedro thanks for the style adjustments. For the intrinsic review of the patch I will use the former attached patch. --> removing review request flag
Comment on attachment 77557 [details] patch for i112701 Review of patch done. Unfortunately, I have to admit that the patch does not solve the problem completely. The check does not work in all combinations of searches and search options. One use case that is not covered is: - Same sample text document, but search-and-replace regular expression $ (paragraph end). The paragraph ends are found, but not replaced.
Some further comments: I think the idea of the patch by checking, if the current selection is the result of a former performed search or a user made selection is the right one. But it can not be check that easy. May be it is needed to mark the selection to be a selection from a former performed search - as a possible solution. This is only an idea - may be there are other and even better solutions. I recognized that the complete "find in current selection" function is broken. If you make a selection which contains two times the string "orw" and you try to find both occurrences by using the find function in the find-and-replace dialog with "in current selection" option, you will not succeed. After you have found the first occurrence your made selection is lost and you will not find the second occurrence. Thus, even more changes/improvements are needed in this area of find-and-replace functions. @bo.tian: Are you willing to do further work on this issue? If not, please assign this issue back to me.
*** Issue 123494 has been marked as a duplicate of this issue. ***
Still Reproducible with "AOO 4.1.0-Dev – English UI / German locale - [AOO410m1(Build:9750) - Rev. 1530680 - 2013-10-11]" on German WIN7 Home Premium (64bit)", own separate user profile. Because of incomplete LCo selector (Bug 123063) no correct information can be left.
Some smaller details might be different, but the core of the "wrong Replace" already are reproducible already with 1.1.5 I tested with LibO (WIN 7) as per original report of "Bug 123494 - Replace without previous Find in selection replaces complete first paragraph of selection": Reproducible with LibO 3.3.3 Fixed in LibO 4.2
Reset the assignee to the default "issues@openoffice.apache.org".