Description: If you try to Find and Replace to adjust formatting, Libre Office crashes- every time, even after updating. Steps to Reproduce: 1.Ctrl +H 2. Find Format [italic] 3. Replace Format [bold italic, Font coloour Green 700] 4 Replace all Actual Results: Error: "undo must be turned off to complete the operation. Do you wish to proceed?" [yes] Libre Writer and Calc Not Responding. Libre Office had to be shut down in Taskman Expected Results: All italic to become bold and green in this perfectly ordinary, minimally formatted 13Kb Writer document. Reproducible: Always User Profile Reset: No Additional Info: Should have taken 5 seconds, without turning off 'Undo', to make all text that's formatted [italic], green and bold as well.
I can't reproduce. Please, can you attach a sample file where the issue happens. Please test in safe mode, Menu/Help/Restart in Safe Mode
Created attachment 189015 [details] Libre writer file
Thank you for looking into this. Will test in Safe mode.
Created attachment 189016 [details] Crash and task manager I'd also rather not have to turn of 'undo' just to do a Find-Replace.
It's still crashing in Safe Mode
I don't see the crash, LibreOffice doesn't end, but seems like in loop to do the replacement, that never ends. Version: 7.6.0.3 (X86_64) / LibreOffice Community Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6c06c8a2be3d8cbbcb8ab1aaaeb04db95114dfcb CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
(In reply to m.a.riosv from comment #6) > I don't see the crash, LibreOffice doesn't end, but seems like in loop to do > the replacement, that never ends. > > Version: 7.6.0.3 (X86_64) / LibreOffice Community > Build ID: 69edd8b8ebc41d00b4de3915dc82f8f0fc3b6265 > CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: > win > Locale: es-ES (es_ES); UI: en-US Calc: CL threaded > > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 6c06c8a2be3d8cbbcb8ab1aaaeb04db95114dfcb > CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: default; VCL: win > Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Thanks for looking at the file and testing the process
Not a bug, for me. You must Find "italic" and "normal" (you must choose "No Bold" in the character Style field). Reproducible with: Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-MX (es_ES); UI: en-US Calc: CL Reproducible since two paragraph with italics (maybe with another formatting). See attachment. Workarounds: - Find for ".*" without quotes. - Find All, then apply the new format/style.
Created attachment 189074 [details] Test case. Two paragraphs with three characters each.
(In reply to LeroyG from comment #8) > Not a bug, for me. > > You must Find "italic" and "normal" (you must choose "No Bold" in the > character Style field). > > Reproducible with: > Version: 7.4.7.2 (x64) / LibreOffice Community > Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 > CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: > win > Locale: es-MX (es_ES); UI: en-US > Calc: CL > > Reproducible since two paragraph with italics (maybe with another > formatting). See attachment. > > Workarounds: > - Find for ".*" without quotes. > - Find All, then apply the new format/style. Thank you. Not quite sure, but I'm assuming you mean that in the FIND field it has to be stipulated that text formatted 'no bold' is to be found. There's no 'normal' and there's no way to specifically stipulate 'no bold' at the same time as stipulating 'italic'. Even were that possible, I'd say that being required to stipulate 'no bold' to italic-formatted text that already isn't bold is pretty bug-like behaviour. Or have I misunderstood? What is needed is to search simply and directly for any formatting attribute desired, and replace that with whatever other formatting is desired, without losing the option to undo the operation (as in Word), and have the operation complete itself in a timely fashion.
Created attachment 189094 [details] Search for formatting and Find and Replace dialogues with No Bold/normal The screenshot shows what can be the bug here: a matter of wording.
(In reply to twentyjazzfunkgreats from comment #10) > Not quite sure, but I'm assuming you mean that in the FIND field it has to > be stipulated that text formatted 'no bold' is to be found. There's no > 'normal' and there's no way to specifically stipulate 'no bold' at the same > time as stipulating 'italic'. See my screenshot (4th attachment). > Even were that possible, I'd say that being required to stipulate 'no bold' > to italic-formatted text that already isn't bold is pretty bug-like > behaviour. In both sample files, at the first search, there are no bold text, only regular and italic. At the second search "round" now also there are bold text, wich also are italic, and green. And being italic, will be found. So, it is an endless loop (see comment #6). Changed status to unconfirmed.
No matter the reasons, if LibreOffice enter an endless loop, it is a bug.
(In reply to m.a.riosv from comment #13) > No matter the reasons, if LibreOffice enter an endless loop, it is a bug. Many thanks for your attention to this
(In reply to LeroyG from comment #11) > Created attachment 189094 [details] > Search for formatting and Find and Replace dialogues with No Bold/normal > > The screenshot shows what can be the bug here: a matter of wording. In my version, there's no way to select 'italic' and 'no bold' together. Only one, the latest, 'sticks'. In any case, note that it's not also requiring 'no underlining', 'no strikethrough' etc. Stipulating what it's NOT shouldn't be necessary.
(In reply to twentyjazzfunkgreats from comment #15) > In my version, What is your version? Copy from menu Help - About LibreOffice. > there's no way to select 'italic' and 'no bold' together. > Only one, the latest, 'sticks'. Open the dialog with the Format button, select and accept one one style, reopen the dialog with the Format button, an then select the other. > Stipulating what it's NOT shouldn't be necessary. Maybe, maybe not. Same behavior with: Version: 6.4.7.2 (x86) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: es-AR (es_MX); UI-Language: en-US Calc: threaded
To reproduce, there must be at least two paragraphs. One can be empty. Not reproducible if there is only one paragraph.
Same behavior with: Version: 7.4.3.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 1; OS: Linux 5.14; UI render: default; VCL: gtk3 Locale: es-MX (en_US.UTF-8); UI: en-US Calc: threaded Since unsaved changes in a document can be lost, Importance, must not be changed to *major*?
(In reply to LeroyG from comment #16) > (In reply to twentyjazzfunkgreats from comment #15) > > In my version, > > What is your version? Copy from menu Help - About LibreOffice. > > > there's no way to select 'italic' and 'no bold' together. > > Only one, the latest, 'sticks'. > > Open the dialog with the Format button, select and accept one one style, > reopen the dialog with the Format button, an then select the other. > > > Stipulating what it's NOT shouldn't be necessary. > > Maybe, maybe not. > > > Same behavior with: > > Version: 6.4.7.2 (x86) > Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 > CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: > default; VCL: win; > Locale: es-AR (es_MX); UI-Language: en-US > Calc: threaded Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
...the bug occurred on the previous version, which was in the 6 es. And continued occurring after an update, which I had hoped would resolve it.