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")
The tool returns "Search key not found".
The tool finds the term in the selected (active) cell.
User Profile Reset: No
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: 188.8.131.52 (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  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.
(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!
Tested and confirmed as still present with the following:
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
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