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.
Dear Zophonías Jónsson, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug