Description: If the font is switched from one to another and the font name is typed in the field at the top, the font name is auto-completed. The first suggested font stays as auto-completion and is not replaced or updated by newly typed letters. Steps to Reproduce: 1. Open a document 2. Change the font name by typing the font name in box in the header bar Actual Results: Font name is auto-completed with the first match in the list, but is not updated when following characters do not match the typed font name Expected Results: The suggested font name is auto-completed, but updates when it no longer matches the user input. Reproducible: Always User Profile Reset: No Additional Info: Because it is not working well, the auto-completion actually hinders the workflow much more compared to it not existing at all. LibreOffice: Version: 25.8.2.2 (X86_64) / LibreOffice Community Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 12; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: de-AT (de_AT.UTF-8); UI: de-DE Flatpak Calc: threaded System Information: Operating System: KDE neon User Edition KDE Plasma Version: 6.5.0 KDE Frameworks Version: 6.19.0 Qt Version: 6.9.2 Kernel Version: 6.14.0-33-generic (64-bit) Graphics Platform: Wayland This might be a Linux and/or KDE thing as I don't recall having this problem under Windows (I might recall incorrectly though)
Created attachment 203574 [details] LibreOffice Writer - Bug 169105 - auto completed font name updated incorrectly Video for the behaviour as described
Hello, is it correct video?
Created attachment 203583 [details] LibreOffice Writer - Bug 169105 - auto completed font name updated incorrectly Correction: Wrong video was uploaded
(In reply to raal from comment #2) > Hello, is it correct video? It was the wrong video from a different bug. Thanks for the heads up. I already uploaded the correct video.
Created attachment 203857 [details] LibreOffice Writer - Bug 169105 - auto completed search updated incorrectly I saw that the same problem applies to the search field. When you search for a value (eg. "Hello World") the text is auto completed next time when you type "Hello" even when you actually want to write "Hello Test". This is rather annoying when you have several search entries that slightly differ at the end of the search term
The font name auto-correct is working as it should on Windows. No reproduce Version: 25.8.2.2 (X86_64) Build ID: d401f2107ccab8f924a8e2df40f573aab7605b6f CPU threads: 32; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
(In reply to jcline from comment #6) > The font name auto-correct is working as it should on Windows. No reproduce I also couldn't reproduce it on my Windows machine. It seems to be a Linux bug (that's why I did set the hardware information accordingly)
Bibisected with linux-64-7.0 to 2e0a32b51681fb356699b4a722f461f55a46b890 weld FontNameBox Only affects gtk3 UI.
I find the video more confusing than explanatory. In some cases it looks like typing begins, a suggestion is offered and then there is a click outside the combobox so it resets to its contents before the editing began, which is expected. I think we always did that. Are you pressing return/enter at the end of typing the font name? On the other hand, at 0:20 "Sans" is selected, at 0:21 "Sans" is not highlighted and content inserts between "S" and "ans". For me if I select "Sans" and type "S" I get "ans" highlighted/selected and when I type "e" after that then it auto-completes to Serif with "rif" highlighted/selected so what I experience doesn't seem to match. Maybe there is a momentary tooltip firing and stealing focus away, and that loses the selection, and then focus is restored, so the cursor is between letters after that, the same as if you explicitly click between them @Buovjaga are you reproducing with this gtk under kde setup, or gtk under gnome? Is there a difference between these two, or am I just failing to see the obvious.
(In reply to Caolán McNamara from comment #9) > @Buovjaga are you reproducing with this gtk under kde setup, or gtk under > gnome? Is there a difference between these two, or am I just failing to see > the obvious. Gtk3 under kde. I focus into the font name box in a new document, delete Serif and start typing Sans. I don't move the focus out.
I think I can reproduce this under KDE. It looks like the problem is with klipper, the clipboard thing in the system tray and disabling it works around the problem. It appear to grab the clipboard, and when the GtkEntry loses the clipboard it drops its selection so we get this problem, which is the sort of things seen in the old upstream issue of https://bugzilla.gnome.org/show_bug.cgi?id=333320
(In reply to Caolán McNamara from comment #11) > I think I can reproduce this under KDE. It looks like the problem is with > klipper, the clipboard thing in the system tray and disabling it works > around the problem. It appear to grab the clipboard, and when the GtkEntry > loses the clipboard it drops its selection so we get this problem, which is > the sort of things seen in the old upstream issue of > https://bugzilla.gnome.org/show_bug.cgi?id=333320 Aha, do you think this should be closed as notourbug? In that case I could report it to KDE.
Given that klipper seems to cause this sort of problem for 20 years I don't expect to see it changed in a hurry. I think I can see a way to avoid this problem on our side with a bit of cunning.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/722f5e3aef579784c28b5e38cb8a9f457409be3b tdf#169105 defeat klipper triggering losing selection during autocomplete It will be available in 26.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified, thanks. Arch Linux 64-bit Version: 26.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 722f5e3aef579784c28b5e38cb8a9f457409be3b CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 8 December 2025
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/43d8805c5f2525739319de886b78806b0bc14970 tdf#169105 defeat klipper triggering losing selection during autocomplete It will be available in 26.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Ooh, I found an existing KDE report: https://bugs.kde.org/show_bug.cgi?id=509975 They did away with the "klipper" brand and now the bugs can be found within the path Plasma -> Plasma Shell -> Clipboard widget & pop-up