Bug 169105 - Writer: Font name is auto-completed but auto-completed text is not updated when the following chars do not match the auto-completed name (gtk3)
Summary: Writer: Font name is auto-completed but auto-completed text is not updated wh...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.0.0.3 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2025-10-27 23:27 UTC by BDF
Modified: 2025-11-20 20:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
LibreOffice Writer - Bug 169105 - auto completed font name updated incorrectly (455.94 KB, video/webm)
2025-10-27 23:28 UTC, BDF
Details
LibreOffice Writer - Bug 169105 - auto completed font name updated incorrectly (1.66 MB, video/webm)
2025-10-28 12:36 UTC, BDF
Details
LibreOffice Writer - Bug 169105 - auto completed search updated incorrectly (125.40 KB, video/webm)
2025-11-10 14:46 UTC, BDF
Details

Note You need to log in before you can comment on or make changes to this bug.
Description BDF 2025-10-27 23:27:32 UTC
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)
Comment 1 BDF 2025-10-27 23:28:54 UTC Comment hidden (obsolete)
Comment 2 raal 2025-10-28 08:42:18 UTC Comment hidden (obsolete)
Comment 3 BDF 2025-10-28 12:36:31 UTC
Created attachment 203583 [details]
LibreOffice Writer - Bug 169105 - auto completed font name updated incorrectly

Correction: Wrong video was uploaded
Comment 4 BDF 2025-10-28 12:37:16 UTC
(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.
Comment 5 BDF 2025-11-10 14:46:16 UTC
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
Comment 6 jcline 2025-11-15 03:51:10 UTC
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
Comment 7 BDF 2025-11-16 23:38:29 UTC
(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)
Comment 8 Buovjaga 2025-11-20 18:10:42 UTC
Bibisected with linux-64-7.0 to 2e0a32b51681fb356699b4a722f461f55a46b890
weld FontNameBox

Only affects gtk3 UI.
Comment 9 Caolán McNamara 2025-11-20 20:11:27 UTC
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.
Comment 10 Buovjaga 2025-11-20 20:26:57 UTC
(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.