1. Open attachment from bug 100535 [1] with LO 5.1.4.x, 5.2 beta or master builds. Observe that the document has no spaces (it has two empty lines, plus "Test" in a text box). 2. Press Down, then Enter (add an empty line at the end). 3. Open Find & Replace, enter " *$" in the Search For field. Leave Replace With field blank. 4. Press "Replace All". 1 replacement will be made. 5. Press "Replace All". 1 replacement will be made. (additional "Replace Alls" yield no further replacements, also the line added in step 2. will be gone) 6. Press Close or [X]. Nothing happens. (until you click outside the dialog, then Close / [X] works again) Results for steps 4-6 are not correct, the regex is supposed to remove trailing spaces, but there are not spaces in the document. This behavior replaces the crash described in bug 100535, but it is a regression. The Close button works fine in 5.1.3.2, and 4.4.0.3 works completely fine. [1] https://bugs.documentfoundation.org/attachment.cgi?id=125819
Forgot an essential part of step 3: check "Regular expressions" under "Other options".
Oliver, I found a commit for Find&Replace hang that was applied in 5.1 between 5.1.3 and 5.1.4.1, do you think that can explain this behavior? (also found the referenced bug report, bug 98224)
(In reply to Aron Budea from comment #0) > 1. Open attachment from bug 100535 [1] with LO 5.1.4.x, 5.2 beta or master > builds. Observe that the document has no spaces (it has two empty lines, > plus "Test" in a text box). > 2. Press Down, then Enter (add an empty line at the end). > 3. Open Find & Replace, enter " *$" in the Search For field. Leave Replace > With field blank. > 4. Press "Replace All". 1 replacement will be made. > 5. Press "Replace All". 1 replacement will be made. (additional "Replace > Alls" yield no further replacements, also the line added in step 2. will be > gone) > 6. Press Close or [X]. Nothing happens. (until you click outside the dialog, > then Close / [X] works again) > > Results for steps 4-6 are not correct, the regex is supposed to remove > trailing spaces, but there are not spaces in the document. > > This behavior replaces the crash described in bug 100535, but it is a > regression. The Close button works fine in 5.1.3.2, and 4.4.0.3 works > completely fine. > > [1] https://bugs.documentfoundation.org/attachment.cgi?id=125819 I have tried your test case on LO Version: 5.1.4.2 (x64) Win7 and is unable to confirm behaviour. Perhaps fixed now? Best Per
(In reply to Per from comment #3) > I have tried your test case on LO Version: 5.1.4.2 (x64) Win7 and is unable > to confirm behaviour. Perhaps fixed now? Best Per Thanks for checking. Can you reproduce the crash in 5.1.3.2 with the same steps? I haven't actually checked with 5.1.4.2, but it's there in master branch and in 5.2.0.1, so I wouldn't expect it to be fixed.
And by crash I mean freeze, as described in bug 100535.
I tested in 5.1.4.2, and could still reproduce it. Did you check "Regular expressions" in addition to step 3., as I added in Comment 1?
I can confirm the described behaviour on recent linux master (d56dc64795dcd913d5fa663275bf34b75a0c82e6) close button not working until you click inside the document and try to close again. But it's not a real freeze as in busy and unresponsive, it just won't close the dialog.
I imagine the dialog doesn't close because its close button calls rBindings.Execute( SID_SEARCH_DLG ); and the same reason that you can't launch the search and replace dialog from inside the drawing box means you can't cancel it when the cursor is in there.
I see that the match claims to success inside the drawing shape which is odd seeing as it shouldn't match surely. And I see that in draw/impress regular expression search is disabled in the search dialog, I suspect because its known not to work
hmm, and anyway the selection that *writer* has is the anchor point not the content inside the drawing this. This only works for "FIND", not replace, or find & replace or find all. Looking at the timing of the original commit I feel this is for libreofficekit search support so I'd like to restrict it to just that mode as a quick fix
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=46b52c22bfb6b145af3c8407fd96321381e78d99 Resolves: tdf#100538 make searching in shape text a libreoffice-kit only thing It will be available in 5.3.0. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e4f935f138d941f537227a344d4b93b05f951457&h=libreoffice-5-2 Resolves: tdf#100538 make searching in shape text a libreoffice-kit only thing It will be available in 5.2.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f12492f72e744bd5b5b016d9c6c85e735948cc4b&h=libreoffice-5-2-0 Resolves: tdf#100538 make searching in shape text a libreoffice-kit only thing It will be available in 5.2.0. 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.