Description: copy plain text in writer select part of plain text " • " whatever search option selected or not, search comes back with Search key not found. similar result with two spaces Steps to Reproduce: 1.create a bullet list 2.cut bullet list 3.paste bullet list as plain text 4. select bullet and spaces surounding bullet 5. search (search term autofilled) 6. fail. Actual Results: Search key not found Expected Results: ability to find and replace all occurences of " • " Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
_observed_ I was unable to reproduce this issue on Windows or Linux, using later versions than the original report. The steps I used were based on these: 1. Start Writer 2. Enter a bullet list (B) followed by some blank lines (see attachment) 3. Select the whole list 4. Ctrl-C 5. Place the caret at the end of the document 6. Ctrl-Shift-V 7. Select Unformatted text 8. Click OK => plain text content is added to the doc 9. Select leading spaces and bullet from one row of the plain content (P) 10. Ctrl-H and click Replace All => all occurrences of that string in P is replaced with "" I found that I can provoke "Search key not found" at (10) in a couple of ways: * adding (e.g.) 20 additional spaces to the search term in (9). This is expected; the search term is not present in the document. * checking Similarity Search before Replace All at (10). This is unexpected; I thought it would still find the bullets in P. (See attachment) Very speculatively, then, the copy done by the original reporter might have inserted characters into the search field that are not in the document. There are related issues along these lines, e.g. bug 91030 _versions_ Version: 7.1.2.0.0+ (x64) / LibreOffice Community Build ID: 90294a92f15218bfd18986053dfeeaeaa99c2fd8 CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded Version: 7.1.1.1 / LibreOffice Community Build ID: 575c5867c4cc13d7ae78f9ce39a54a52ed38c769 CPU threads: 1; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Linux was Ubuntu 20.04.02 running inside VirtualBox on Windows 10.
As well as the repro reported in comment 1 I tried variations including these, but none of them showed the behaviour in comment 0: 3. select part of B rather than all of it => search/replace succeeds 4. Ctrl-X rather than Ctrl-C => search/replace succeeds 5. Place the caret at the start of the document, so P is pasted over B => search/replace succeeds 9. selecting different numbers of spaces around the bullet, including just the bullet => search/replace succeeds 10. Ctrl-F instead of Ctrl-H & return instead of Replace All => find bullets in P
Created attachment 170108 [details] "Search key not found" with Similiarity Search
Created attachment 170109 [details] Document for repro (comment 1)
Hello Rototo, Could you please try to reproduce it with version 7.1.3.2 of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Tested & works correctly in 7.1.3.2.
(In reply to Rototo from comment #6) > Tested & works correctly in 7.1.3.2. Nice, closing as RESOLVED WORKSFORME