Bug 126752 - Find & Replace should optionally also make use of AutoCorrect single or double quote substitutions for easier keyboard search entry
Summary: Find & Replace should optionally also make use of AutoCorrect single or doubl...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
: 146651 (view as bug list)
Depends on:
Blocks: Find-Search AutoCorrect-Complete
  Show dependency treegraph
Reported: 2019-08-07 19:18 UTC by Mike Blumenkrantz
Modified: 2022-01-10 09:04 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Mike Blumenkrantz 2019-08-07 19:18:10 UTC
If I attempt to find ' or " in a writer document, libreoffice always reports "Search key not found" and fails to return any results.

1. Open writer document
2. Add some text which includes double/single quotes
3. Use ctrl+f to try and search for any string including ' or "
4. No results

I am currently running on Fedora 30, and I have made no changes to the default libreoffice configuration.
Comment 1 Regina Henschel 2019-08-07 22:09:50 UTC
I cannot confirm it, it works for me.

Which "Find" do you use? Find-bar or full dialog?

Are you searching for the correct version of the characters? Curly vs. straight?
Comment 2 Mike Blumenkrantz 2019-08-08 00:00:54 UTC
Now that you mention it, libreoffice seems to automatically convert my normal ' and " characters to the curly variants on the page, but it doesn't do this in the find bar.

This is the default setting of libreoffice, and I have no way on my keyboard layout to manually trigger a curly ' or ", so it's impossible to even search for what libreoffice is changing my text to.
Comment 3 V Stuart Foote 2019-08-08 04:30:05 UTC
That is an Autocorrect feature replacing Start and End single and double quotes when entering ' (0x27), or " (0x22) via keyboard.

You need to search for the replacement assigned.

You can identify and modify the replacement glyph /code point from:

Tools -> AutoCorrect -> AutoCorrect Options on the 'Localized Options' tab. Clicking the Start or End box for single or double quotes will launch the Special Character dialog which will identify the glyph / code point and allow selection of a different.
Comment 4 Mike Blumenkrantz 2019-08-08 04:34:44 UTC
Yeah, I understand that I can do that now. But this is definitely a bug.

The default configuration for libreoffice is to do this replacement. It should therefor ALSO be the default configuration that when I ctrl+f to search for a ' or " character, this searched-for character gets replaced so that I'm able to find it.

This is non-obvious and unintuitive to new users, not to mention it's very annoying to always have to use my mouse to select the exact character that I want to search for (which I'm unable to even type with my keyboard layout).
Comment 5 V Stuart Foote 2019-08-08 12:34:06 UTC
No, it functions as implemented => NAB.

But not unreasonable to do as an RFE to the Find & Replace dialog. Implement a feature to optionally use the values set for AutoCorrect of single and double quote glyph.

Would need to be configurable. Ideally in GUI, from either the AutoCorrect dialog, or in the Find & Replace dialog, alternatively as Expert Configuration stanza.

To UX advise...
Comment 6 Heiko Tietze 2019-08-09 10:24:22 UTC
Wouldn't add any UI controls. Search should also include characters from autocorrection. If users explicitly want search for ' even when replaced by the curly variant, eg. for some kind of citations, h/she has to use the regex function. If we add a checkbox "[ ] Include text from auto-correction" it makes the dialog not easier not to speak of the quick find bar. In that case I vote for WF.
Comment 7 Thomas Lendo 2019-08-13 20:54:12 UTC
This is an old issue that I call 'usability bug' as it's not intuitive for the user. I thought there was a bug or I talked about it, but I couldn't find any older sources. I added some other quote bugs in the search field in 'see also'. To this issue:

In many cases the search field should behave like normal text with its auto-complete settings. Otherwise the user can't search for strings that LibreOffice changes automatically -- how should the user know which Unicode the modified strings have?

But Heiko is also right that someone wants to search for the original string.

I suggest a new option in the AutoCorrect > Options dialog tab where the user can deactivate the new default behavior (which is auto-correction is activated also in the search field).

Additionally I suggest to deactivate the auto-correction temporarily with a shortcut like 'alt' during typing in the search field. This prevents going into the options for a single search.
Comment 8 Heiko Tietze 2019-08-15 07:24:11 UTC
We discussed this topic in the design meeting. The implementation requires a general approach, ie. all autocorrection terms have to handled similarly. Technically it might be challenging to run the search twice if some string might have been replaced (for example ' by " where users can undo the autocorrection so consequently we have to search first for ' and subsequently for "). 

So we suggest to simply show a message that this input might have been autocorrected. It could be something like "No results found but <foo> might have been replaced by <bar>." as an enhancement to the current information.
Comment 9 TH 2020-11-27 18:50:16 UTC
No, the best implementation to correct this usability deficit would be to automatically search for both the non- and auto-corrected forms when the search string contains commonly-used characters such as ' " ellipsis etc.  The search functionality should be smart enough to recognize that the search string contains character(s) that may have been auto-corrected / substituted, and either a) automatically search for all possible strings based upon autocorrection / no correction, or provide an checkbox to specify to the search functionality that autocorrected variants are to be included.  Also, there should be a way to easily specify a wildcard character (e.g., "?" and "*", which are common OS conventions) to match any underlying text, with a corresponding checkbox to indicate that a wildcard search is intended.
Comment 10 Heiko Tietze 2022-01-10 09:04:13 UTC
*** Bug 146651 has been marked as a duplicate of this bug. ***