In the Find & Replace dialog, if Control-Shift-Space is typed into the "Search For" or "Replace With" fields, the currently-selected text in the documented is deleted and replaced by a no-breaking space. This is totally inexplicable behavior, even if Find & Replace does not work with non-breaking spaces for some reason. When the input focus is in the dialog, keyboard input should not go to the main document. Typing anything else into the "Search For" box does not replace the currently-selected text in the document with what is typed (as expected). STEPS TO REPRODUCE: 1. Open a Writer document containing text, or create a new one with text. 2. Control-A (select all) 3. Control-H (open Find & Replace) 4. Click in the "Search For" box 5. Type Control-Shift-Space ACTUAL RESULTS: The selected text in the document disappears, and is replaced by a non-breaking space (use View->Non Printing Chars to see it). EXPECTED RESULTS: A non-breaking space should be entered into the search box
I can confirm with LO 4.4.0.3, win7
An easier way to search non-breaking space is to search \u00A0 (unicode character). Do not forget to check the Regular Expressions checkbox in Other options in the search & replace dialog. Best regards. JBF
*** Bug 93500 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Confirming bug is still present in 5.2.3.0.0+ (master)
Bug still present in V5.3.0 Writer. Similar Bug in V5.3.0 Calc: Entering Shift+Ctrl+Space in 'F&R' (either Search For or Replace With) is resulting in a 'Select All' for the current context in the document. If a cell, a cell range or a multirange is selected in advance, the complete sheet gets selected. If a cell was under editing the complete content of the cell gets selected.
Confirmed in Version: 6.0.4.2 Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 4; OS: Mac OS X 10.9.5; UI render: default; Locale: en-US (en.UTF-8); Calc: group
Dear Jim Avera, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Confirming the bug is still present in: Version: 6.3.0.0.beta1 Build ID: a187af327633f5f00363be5131bd21a13e0f1a7b CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; Locale: en-US (en_RU.UTF-8); UI-Language: en-US Calc: threaded
Partially fixed in latest Master: Selected text in the main window is not longer replaced or deleted if Control-Shift-space is typed into the "Find" field of the Search-and-replace dialog. However, nothing happens at all; a non-breaking space is not entered into the Find field, and you can not search for it typed that way.
Clarification: A non-breaking space can not be typed using Conrol-Shift-space (the documented way) when entereing Find or Replace fields. In those fields Control-Shift-space does nothing at all -- it is silently ignored. As Jean-Baptiste pointed out, it is possible to use the \u00A0 escape with Regular Expressions enabled, so the underlying search mechanism works. However users should be able to use the documented way of typeing a non-breaking space (control-shift-space), and should not need to know Unicode encodings or Regex syntax to just search for text which they typed into the document body. Version: 6.4.0.0.alpha0+ Build ID: f75c2b04785aa05cff3bcd52689feb7400a14e8e CPU threads: 12; OS: Linux 4.18; UI render: default; VCL: gtk3; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2019-06-15_11:49:26 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
*** Bug 132395 has been marked as a duplicate of this bug. ***
the F$R dialog box does not show anything when I press "CTRL ALT Space" "narrow_no_break_space" U+202F Version: 7.1.0.3 / LibreOffice Community Build ID: 10(Build:3) CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Dear Jim Avera, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The remaining bug (can't use documented way to type nb-space into search box) still exists in recent master. Revised STEPS TO REPRODUCE: 1. Create a writer document with some text containing both regular and non-breaking spaces For example, type "Hello Beautiful<CTL-SHIFT-SPACE><CTL-SHIFT-SPACE><CTL-SHIFT-SPACE>World!" 2. View->Formatting Marks (checked) You should see a blue dot for the regular space, and white spaces for the non-breaking spaces entered using <CTL-SHIFT-SPACE>. 3. Edit->Find and Replace (or ^H) Put cursor in "Find:" fields and type <CTL-SHIFT-SPACE> RESULTS: Nothing happens, no text is entered and you can't search for it. EXPECTED RESULTS: <CTL-SHIFT-SPACE> should enter a non-breaking space. NOTE: As mentioned by Jean-Baptiste it is possible to enter the hex Unicode code point and successfully search for non-breaking spaces, so the underlying machinery handles this correctly -- it is a problem with keyboard input. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 16a35542aa07ed69c6c699d1c17f076d87708958 CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded