Description: Since a couple of minor updates ago, the keyboard response in dialog boxes has changed and become inconsistent. In some dialog boxes, hitting ENTER still confirms the value entered and closes the dialog box. This is how dialog boxes tend to work in all programs on all platforms. It is quicker and reduces the need for unnecessary mouse clicks. However, many dialog boxes (e.g. Format→Character), ENTER only confirms the value but doesn't close the box. The box can only be closed with a mouse click, or by clicking the focus through to the 'OK' button with TAB and then hitting ENTER. Also, the ability to click through to the next/prev tab within a dialog box by means of [SHIFT-]CTRl-TAB has stopped working. Now, a mouse click is needed, or one has to TAB the focus to the tab heading and use arrow keys. These changes reduce functionality and I can only imagine that they are accidental - especially since they don't apply to Windows. Steps to Reproduce: 1. Open dialog box 2. Enter value 3. Hit 'RETURN/ENTER' key Actual Results: The new value is confirmed, the dialog box remains open, cursor remains in the box amended Expected Results: The new value is confirmed, the dialog box closes Reproducible: Always User Profile Reset: No Additional Info:
(In reply to Tapani from comment #0) > However, many dialog boxes (e.g. Format→Character), ENTER only confirms the > value but doesn't close the box. I can't confirm that with Version: 6.3.2.2 (x64) Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded To be certain the reported issue is not related to corruption in the user profile, could you please reset your Libreoffice profile (https://wiki.documentfoundation.org/UserProfile) and re-test? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the issue is still present.
(In reply to Dieter Praas from comment #1) > (In reply to Tapani from comment #0) > > However, many dialog boxes (e.g. Format→Character), ENTER only confirms the > > value but doesn't close the box. > > I can't confirm that with > > Version: 6.3.2.2 (x64) > Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c > CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win; > Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE > Calc: threaded I should have been clearer: this only affects my Linux installation. It does not affect LO Writer on Windows. I have three Linux installations, and this affects them all.
Could you please paste the info from Help - about LibreOffice ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the information has been provided
(In reply to Xisco Faulí from comment #3) > Could you please paste the info from Help - about LibreOffice ? > > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' once the information has been provided Version: 6.3.2.2 Build ID: 1:6.3.2-0ubuntu0.19.04.1~lo1 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
Unconfirmed on Debian 9.11 Version: 6.3.2.2 Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 4; OS: Linux 4.9; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded [SHIFT-]TAB is the key sequence that will provide the functionality you are describing - click through to the next/prev tab within a dialog box. [SHIFT-]CTRL-TAB will switch between open tabs on a browser or open spreadsheets in Calc. [SHIFT-]CTRL-TAB will not click through to the next/prev tab within a dialog box. Writer: [SHIFT-]TAB moves through selections correctly. Example: on "Bullets and Numbering"→"Position" choices. Pressing Enter works correctly. Example: Changing the value in "Tab stop at:" and pressing enter confirms the new value and closes the dialog box. Could you please confirm the functionality expected for [SHIFT-]TAB works per your expectations? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' or 'RESOLVED'.
This is part of the functionality that has broken down. This is how it used to function, this is how my Windows copy functions, but now ctrl-tab & shift-ctrl-tab work like tab & shift-tab.
First of all, for me, both with 6.3 and master (using gtk3 backend), the Character formatting dialog closes after changing a value and hitting Enter. To be sure, please be more specific about which field you are manipulating in the Character formatting dialog. Second, if the keyboard behaviour changed in relation to tabs, it must be because the dialogs now use native gtk: https://caolanm.blogspot.com/2019/10/native-gtk-dialogs-in-libreoffice.html This means LibreOffice adapts to the gtk way of doing things and it certainly might be different from Windows.
(In reply to Buovjaga from comment #7) > First of all, for me, both with 6.3 and master (using gtk3 backend), the > Character formatting dialog closes after changing a value and hitting Enter. > To be sure, please be more specific about which field you are manipulating > in the Character formatting dialog. Setting to NEEDINFO
(In reply to Xisco Faulí from comment #8) > (In reply to Buovjaga from comment #7) > > First of all, for me, both with 6.3 and master (using gtk3 backend), the > > Character formatting dialog closes after changing a value and hitting Enter. > > To be sure, please be more specific about which field you are manipulating > > in the Character formatting dialog. > > Setting to NEEDINFO This problem now applies to all dialogue boxes on all my ubuntu-gnome installations. It does not occur in other programmes.
Hi Tapani, Did you clean the user profile as described here https://wiki.documentfoundation.org/UserProfile ?
(In reply to Xisco Faulí from comment #10) > Hi Tapani, > Did you clean the user profile as described here > https://wiki.documentfoundation.org/UserProfile ? Yes. This made no difference
Hello Tapani, A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Tapani, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
The bug is still present. My current LO version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 I'm on Ubuntu 20.10 (Gnome Flashback Metacity desktop)
(In reply to Tapani from comment #14) > The bug is still present. > My current LO version: > 7.0.3.1 (x64) > Build ID: d7547858d014d4cf69878db179d326fc3483e082 > > I'm on Ubuntu 20.10 (Gnome Flashback Metacity desktop) Compared to 2019, did your desktop change? I found this info about it: https://wiki.gnome.org/Projects/GnomeFlashback
(In reply to Tapani from comment #0) > Description: > However, many dialog boxes (e.g. Format→Character), ENTER only confirms the > value but doesn't close the box. The box can only be closed with a mouse > click, or by clicking the focus through to the 'OK' button with TAB and then > hitting ENTER. > No repro with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: ba7db98cca3d8516697c94ef0d6af27db9e1655e CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Tested with Format→Character, changed border padding, hit Enter. Dialog closed.
Thanks for reporting this issue. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
(In reply to Xisco Faulí from comment #17) > Thanks for reporting this issue. > Could you please try to reproduce it with the latest version of LibreOffice > from https://www.libreoffice.org/download/libreoffice-fresh/ ? > I have set the bug's status to 'NEEDINFO'. Please change it back to > 'UNCONFIRMED' if the bug is still present in the latest version. Yes, it's still a problem. Nothing has changed.
(In reply to Buovjaga from comment #15) > (In reply to Tapani from comment #14) > > The bug is still present. > > My current LO version: > > 7.0.3.1 (x64) > > Build ID: d7547858d014d4cf69878db179d326fc3483e082 > > > > I'm on Ubuntu 20.10 (Gnome Flashback Metacity desktop) > > Compared to 2019, did your desktop change? I found this info about it: > https://wiki.gnome.org/Projects/GnomeFlashback Do you remember, if you used Gnome Flashback already in 2019? Can you reproduce the problem in a session that is not Gnome Flashback?
(In reply to Buovjaga from comment #19) > (In reply to Buovjaga from comment #15) > > (In reply to Tapani from comment #14) > > > The bug is still present. > > > My current LO version: > > > 7.0.3.1 (x64) > > > Build ID: d7547858d014d4cf69878db179d326fc3483e082 > > > > > > I'm on Ubuntu 20.10 (Gnome Flashback Metacity desktop) > > > > Compared to 2019, did your desktop change? I found this info about it: > > https://wiki.gnome.org/Projects/GnomeFlashback > > Do you remember, if you used Gnome Flashback already in 2019? Yes, I was. > Can you reproduce the problem in a session that is not Gnome Flashback? The same problem exists in Gnome as well.
(In reply to Tapani from comment #18) > Yes, it's still a problem. Nothing has changed. Any change during the last year? Seems to be a very rare case. => NEEDINFO
(In reply to Dieter from comment #21) > (In reply to Tapani from comment #18) > > Yes, it's still a problem. Nothing has changed. > > Any change during the last year? Seems to be a very rare case. > => NEEDINFO Strangely enough, there's no change.