Description: Whenever a dead key (i.e. accent or umlaut) is pressed the cursor advances to the next line. This happens only IF the cursor is at the end of line AND there are lines of text or graphics below the text being entered (i.e. not in the last line of text). This only applies to LibreOffice Writer. The problem seems to be in the libreoffice-qt5 integration as writer behaves normally when libreoffice-qt5 is uninstalled and works correctly with libreoffice-gtk3 integration. This bug has been around for several months. I can confirm this behviour in LibreOffice version 7.5.5.2 (on OpenSuse Leap 15.4) but it was also present in some previous versions. Steps to Reproduce: 1.Select a keyboard with deadkeys (i.e. Icelandic keyboard) and open LibreOffice Writer 2.Create a new document 3.Enter some lines of text 4.Make a blank line that is not the last and try to enter some text with accented characters using the dead-comma Actual Results: cursor advances to the next line Expected Results: accented character inserted when next key is struck Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 12; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Same behaviour on multiple systems with a similar setup.
I just found out that the same problem has been described several times before in the discusson of bug 71437 wich is marked as RESOLVED WORKSFORME. Starting with comment 39 (2022-04-29). It seems that the bug is not really resolved.
Can't reproduce in: Version: 7.6.1.1 (X86_64) / LibreOffice Community Build ID: c7cda394c5de06de37d8109c310df89a4d4c3a98 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5 (cairo+xcb) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded I installed libreoffice-qt5 as well. Can you provide an example document that makes it easy to test it, using a font that we all have? (e.g. Liberation Serif) Thank you!
(In reply to Stéphane Guillou (stragu) from comment #2) It may not be worth spending much time on this. After upgrade to OpenSuse Leap 15.5 which downgrades LibreOffice to 7.5.4.1 this problem is fixed. I can also not reproduce it on OpenSuse Tumbleweed with LibreOffice 7.6.1.1. Since it seems to be caused by some interaction of packages in an OS version that is now outdated I think the bug can be closed. Having said that. An example document would simply be three lines of random text. Something like this: --- Here is the first line. Line two. Type your characters: Áóéí äëï etc. at the end of this line: Here is the last line. --- This can be copy-pasted into a blank document. The problem is font independent.
[Automated Action] NeedInfo-To-Unconfirmed
Unfortunately I celebrated prematurely. The behaviour is back even in Leap 15.5 on one of my computers. This might be difficult to confirm or troubleshoot, but the example above works. Font independent. Version: 7.5.4.1 (X86_64) / LibreOffice Community Build ID: 50(Build:1) CPU threads: 16; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
You could report it in https://bugzilla.opensuse.org/
(In reply to Buovjaga from comment #6) > You could report it in https://bugzilla.opensuse.org/ I'll look into it. With recent updates the bahaviour is back on Leap 15.5 even with LibreOffice 7.6.2 but the workaround, uninstalling libreoffice-qt5 and blocking it so that it doesn't get pulled back in works.
(In reply to Zophonías Jónsson from comment #7) > (In reply to Buovjaga from comment #6) > > You could report it in https://bugzilla.opensuse.org/ > > I'll look into it. > > With recent updates the bahaviour is back on Leap 15.5 even with LibreOffice > 7.6.2 but the workaround, uninstalling libreoffice-qt5 and blocking it so > that it doesn't get pulled back in works. The qt5 UI is not ready for production and distributions should not enable it. However, if you can reproduce it with kf5, then it is more serious.