Description: When using the "find & replace" tool after clicking on a single cell and using the "current selection only", the tool will not find a search criteria even if it exists in the active cell. I think this is not intuitive. I assume most people would consider that the active cell they just clicked on is considered a "selection". I am aware of the fact that it is not highlighted like a cell range would be, and that it is possible to click and drag from A1 over to A2 and back to A1 in order to highlight what we could call a "single-cell range", but that would not be straight-forward. An active cell is in my opinion a selection, and I can't think of a case when the active cell is not part of a selected range. In my opinion, the following is a further confirmation that this is a bug: When the active cell contains something, the option "Current selection only" is selectable; however, when the active cell is empty, the option "Current selection only" is greyed out. This shows that the tool differentiates between active cells that contain something and cells that don't, just like it does for ranges. Steps to Reproduce: 1. Open a new document 2. Write "blah" in cell A1 3. Click on cell A1 4. Open the "Find & Replace" tool 5. Write "blah" in the "Find" field 6. Tick the option "Current selection only" 7. Click "Find All" (or alternatively, click "Replace All") Actual Results: The tool returns "Search key not found". Expected Results: The tool finds the term in the selected (active) cell. Reproducible: Always User Profile Reset: No Additional Info: System details: Version: 5.3.5.2 Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU Threads: 2; OS Version: Linux 3.13; UI Render: default; VCL: kde4; Layout Engine: new; Locale: en-GB (en_GB.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
...actually, I can now think of a case when an active cell is not part of a selection: when selecting multiple cells with ctrl+click and deselecting a cell from the selection with a final ctrl+click. To me, it would make sense to: - keep the current behaviour for multiple-cell selection; - in the absence of a selection (i.e. highlighted cell(s)), consider the current active cell as the selection. But I guess that would be considered an inconsistency. Maybe we could easily fix this and make everyone happy with greying out the "current selection only" when there is no highlighted selection? That would be enough of a hint to make the user understand that the active cell is *not* a selection.
@Stuart, please have a look.
On Windows 10 Pro 64-bit en-US with Version: 5.4.1.2 (x64) Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527 CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: group Confirming STR of the non-selection with just the currently active cell with cursor focus, or the misbehavior of the "Current selection only" option which shows active with just the one cell with cursor focus as a "range". Selecting one additional cell produces valid search result. So seems like we have a logic flaw and test the view shell for HasSelection() at [1] enabling the "Current selection only" option-with just the one cell with cursor focus. Is it a valid selection range or not? If it is--the search needs to accommodate a one cell range. If not--need to keep the Selection Btn disabled. From UX perspective, searching just a single cell is not a common use, but why not? Could be of some use in macro to conditionally test a cell. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/svx/source/dialog/srchdlg.cxx?a=true#915
(In reply to V Stuart Foote from comment #3) > From UX perspective, searching just a single cell is not a common use, but > why not? Could be of some use in macro to conditionally test a cell. Is the expectation to find 'lo' in 'Hello World'? Or a certain part of a formula, to be more specific.
** 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 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
Tested and confirmed as still present with the following: Version: 6.0.6.2 Build ID: 1:6.0.6-0ubuntu0.18.04.1 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_GB.UTF-8); Calc: group
Confirmed in: Version: 6.3.0.1 Build ID: 41ac97386aba908b6db860cfb4cfe2da871886ae CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
Reteested in Version: 7.0.1.2 Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded Not working for 1 cell selection. Working for that cell plus any other cell selection.
*** Bug 136496 has been marked as a duplicate of this bug. ***
Still reproducible in: Version: 7.3.0.0.beta1 / LibreOffice Community Build ID: 436f14c25ec1847646b953cf13d0db4f7ca3be57 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Already the case in: Version: 5.2.0.0.alpha1 Build ID: 902b28a39528b6c92602e9b521a1d0861be1caf9 CPU Threads: 4; OS Version: Linux 5.4; UI Render: default; Locale: en-AU (en_AU.UTF-8)
Nitpick: clicking on a cell does *not* result in a selection, just an active cell; note also that the dialog's "Current selection only" is not automatically activated for just an active cell, because it is *not* a selection, and activating "Current selection only" does not magically result in the cell being selected, so the subsequent action of "search in selected cells only" of course does not find anything. To *select* 1 cell, Ctrl+Click the cell again, or select it with the keyboard sequence Shift+Down followed by Shift+Up, or Shift+Right followed by Shift+Left (or other combinations of invert direction selection). Also, the differentiation between active cell and selected cell should not be eliminated as it can lead to ambiguities as comment 1 lined already out; as is, the differentiation and non-presence of a selection makes many state checks for range or multiple selections unnecessary. If there is no selection then the "Current selection only" option could be disabled; however, note that the dialog is non-modal and un-/selecting cells while the dialog is open is possible, so dis-/enabling the option should follow the then current state, not being a one-time-set.
I have encountered an issue with the "Find & Replace" tool in LibreOffice Calc. When attempting to use the "Current selection only" option after clicking on a single cell (the active cell), the tool does not find the search criteria, even if it exists in the active cell. In my opinion, an active cell should be considered a "current selection," as it is the cell I have interacted with and is the starting point for the search operation. It is not intuitive that this does not work as expected. I have observed that when the active cell contains content, the "Current selection only" option is selectable, but when the active cell is empty, the option is grayed out. This distinction implies that the tool recognizes the active cell's content status, just like it does for cell ranges. ref: https://thestyledare.com/product/granite-slab/van-gogh/