Description: When opening csv files the text import dialogue appears with 'Character set' focused instead of 'OK'. LibreOffice 6.3.5 and earlier do not have this issue. clicking the OK button works as expected. Steps to Reproduce: 1. $ libreoffice6.4 file.csv or File->Open and select csv file. 2. Press enter. Actual Results: Character set selection menu appears Expected Results: Pressing Enter imports the csv file. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 6.4.1.2 Build ID: 4d224e95b98b138af42a64d84056446d09082932 CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
Can't reproduce on Windows 10 with 6.4.1 RC1: 版本: 6.4.1.1 (x64) Build ID: 56f3c78975db08733f771c53643b5d1aa7c57567 CPU 线程: 2; 操作系统: Windows 10.0 Build 18363; UI 渲染: 默认; VCL: win; 区域语言: zh-CN (zh_CN); UI 语言: zh-CN Calc: threaded The focus seems to be in a "dual status" on Windows for Text Import dialog, that is, both the Character Set dropdown box and the OK button seem to be highlighted; pressing "Alt+Down" expands the Character Set list, while pressing "Enter" imports the file. Is this a Linux or gtk3 VCL bug only?
On Debian 10 I have both 6.3.5.2 and 6.4.1.2 installed Libreoffice 6.3.5.2 works the same as you are seeing on Windows "pressing "Alt+Down" expands the Character Set list, while pressing "Enter" imports the file". Is there any other information that I can provide?
(In reply to John Hills from comment #2) > Is there any other information that I can provide? Not really. Your description of the bug is clear enough. We just need someone using Linux to reproduce your bug. Meanwhile, if you want to help investigating, you can try setting the environment variable SAL_USE_VCLPLUGIN to gen, something like $ SAL_USE_VCLPLUGIN=gen libreoffice6.4 file.csv to force LO to use X11 instead of GTK3, and see if it changes anything.
Setting the environment variable SAL_USE_VCLPLUGIN to gen (force X11) does solve this issue, so I guess this issue is related to GTK.
I can confirm exactly the original report using Debian 6.4.1, and that it is GTK3-specific. The focus not being on the "OK" button happens on other some dialogs as well, but I so far have found it most annoying on CVS import. It seems that many dialogs are focusing on the first element in the dialog, whatever that may be, so that pressing "enter" in dialogs no longer accepts & closes but instead does something different in each dialog.
The focus hasn't changed, the character set always had the default focus (e.g. on initial focus up/down changes the current character set in older versions). What's changed is that on pressing return the default key bindings for a real gtk-combobox pops up the combobox instead of passing the keystroke up to the dialog in order to activate the default-button ok
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7a078207fbfd71b33cb51c38b3886351fedcde8d tdf#131076 allow 'return' in GtkComboBox to activate default widget It will be available in 7.0.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.
well, that makes it work as the gen backend does, with the risk that its then less-standard behaviour for usual gtk applications, so lets let that settle for a while to see if a pitchfork wielding mob assembles for the other interaction direction before considering a backport
I have reopened this bug as fixing this 7.0 is not acceptable to me, this issue was introduced in 6.4, all/most prior versions did not have this issue: To workaround this issue the choices are: 1. Stay with 6.3.5 (no issue) 2. Wait for 7.0 (who knows when) 3. Disable GTK3 with SAL_USE_VCLPLUGIN=gen or for Debian-backports remove libreoffice-gtk3 A common workflow is to open/import a csv file and press 'enter'
I made a decision to not immediately backport the initial fix until a little time has passed to tease out any potential issues of that fix, that's borne out by bug 131223. The delay will probably make no difference to you in the sense that the final fix will probably still hit the next scheduled release. reopening is unfriendly and not appreciated
> […] who knows when […] This is when, FWIW: https://wiki.documentfoundation.org/ReleasePlan#7.0_release
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/35d451044f2873a9e9f566044cd4ab26b6dfbab0 tdf#131076 allow 'return' in GtkComboBox to activate default widget It will be available in 6.4.3. 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.
In bug 132828, an Ubuntu 20.04 user claims that he is experiencing this bug. They have version 1:6.4.3-0ubuntu0.20.04.1 of Ubuntu native package installed, which is based on 6.4.3 final release. So it would be nice if someone can test LO's own 6.4.3 release to verify this is fixed, and we can leave that user's problem to Ubuntu packagers.
This bug is not fixed in either the stock 6.4.3 nor in Debian's current release. Focus is still character set.
(In reply to bchemnet from comment #14) > This bug is not fixed in either the stock 6.4.3 nor in Debian's current > release. Focus is still character set. Thanks for the feedback. Two reports about 6.4.3 still being buggy, let's REOPEN then. @Caolán, can you have another look?
*** Bug 132828 has been marked as a duplicate of this bug. ***
Because the title of the bug is a bit misleading, note that the combobox still has focus in 6.4.3 (see comment #6) but now pressing return in the combobox activates the ok button instead of popping up a dropdown which was the problem fixed. Checking my local LibreOffice 6.4.3.2 (Fedora 32) when I open a csv I have focus in the character-set combobox (as it always has been IIRC) but pressing return activates ok as expected so I see no bug.
I can confirm that this bug is fixed in 6.4.3.2 from on Debian buster-backports
My experience, both with stock 6.4.3.2 and Debian 6.4.3.1, is that pressing enter activates the character set box, NOT the OK button. I cannot explain why my experience is different, but this bug is still present for me.
Correction: Debian is also 6.4.3.2.
(In reply to Caolán McNamara from comment #17) > Checking my local LibreOffice 6.4.3.2 (Fedora 32) when I open a csv I have > focus in the character-set combobox (as it always has been IIRC) but > pressing return activates ok as expected so I see no bug. Copying from bug 132828: "Pressing Enter in the Text Import dialog now opens a dropdown list of Character sets." and their LO version info is: Version: 6.4.3.2 Build ID: 1:6.4.3-0ubuntu0.20.04.1 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded so it's apparently still bothering some users, not just their misconception about the focus. Should we open a new bug or keep the discussion in this one?
I can confirm that the issue is present both in the Ubuntu package (see the duplicate bug 132828) and in the fresh download from libreoffice.org: Version: 6.4.3.2 Build ID: 747b5d0ebf89f41c860ec2a39efd7cb15b54f2d8 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
I installed Ubuntu 20.04 under VirtualBox, the initial LibreOffice version was 6.4.2 which still had the bug, I apt-updated it to the latest version (Build ID: 1:6.4.3-0ubuntu0.20.04.1) which was 6.4.3.2 and it didn't have the bug. But that's the exact version reported in bug #132828 as not working.
I have just tried on a freshly restarted computer to ensure no possible libs in memory to confuse the issue, with libgtk also fully up to date, and a fresh Libreoffice profile. Pressing enter still opens Character Set, not the OK button, whenever I open a CSV file. I am willing to test further but I have no idea what else to try or what is causing the difference of behavior.
A wild guess, but won't hurt to try - which enter key are you guys using, the one with the main keyboard, or the one on the numpad? Can you try the other one and see if it gives different result? I think they have different keyboard opcodes.
No change. The two are different opcodes (36 & 104 on my desktop), but have the same behavior.
I cannot think of any reason why this would be relevant, but just in case: I am running XFCE (4.14, so GTK3) as my window manager etc. Is it possible that the change works under GNOME only?
Another check here: running in a Wayland session makes no difference either.
I may have a hint: the issue is specific to dialogs where a dropdown is the default (highlighted) control. Try the following: 1. [Bug] File / Open / some CSV file. In the Text Import dialog the Character Set dropdown is highlighted. Pressing Enter opens the dropdown. It should instead activate OK to open the document. 2. [Counterexample] File / Print. In the Print dialog the Number of Copies spinner is highlighted. Pressing Enter activates OK and prints the document. 3. [Counterexample]. Still in the Print dialog, go to tab Libreoffice Calc. The Suppress etc checkbox is highlighted. Pressing Enter activates OK and prints the document. 4. [Bug] File / Printer Settings. In the Printer Setup dialog the Name dropdown is highlighted. Enter opens the dropdown instead of activating OK to accept the settings. 5. [Counterexample]. Data / Define Range. In the Define Database Range the Name inputbox is highlighterd. Enter closes the dialog. 6. [Bug] Sheet / Tab Colour. The Palette dropdown is highlighted. Enter opens the dropdown instead of accepting the chosen setting and closing the dialog. There are probably more examples to be found, but it looks like this is the pattern: the bug occurs where a dropdown is the default control on a dialog.
I have the same experience as Marco. And it is not just the first field that has focus - if I tab around any dialog, as soon as a dropdown box has focus, pressing enter opens the list intead of closing the dialog. In any other field element, pressing enter activates OK. I tried this in a variety of dialogs. So apparently the real issue is that, for some of us, opening a dropdown box in a dialog takes precedence over OK when pressing enter, whereas in all other fields pressing enter activates OK/close/whatever the default button is. Note that this only seems to be true if the dropdown box is reachable using Tab. In some dialgos, such as Export, the file type dropdown does NOT exhibit this behavior. That dropdown cannot be tabbed to/loses focus as soon as something is selected.
bchemnet: the type dropdown in the Export dialog is reachable via reverse (shift) tab, and then exhibits the same behaviour. In fact, the issue isn't due to dialogs having a dropdown as the default control. It's more general: in any dialog where a dropdown has the focus, it "captures" Enter to display its list, rather than leaving it to the dialog's OK. I expect Enter to OK and accept a dialog, even when the focus is on a dropdown, even if I just tabbed the focus to it. Here's an illustration: in Firefox open History / Clear Recent History. The "Time Range to Clear" control is highlighted. For extra drama, use the arrow keys to scroll the value to "Everything". Now, would you press Enter to open the dropdown?
what's needed here now is a reproducible scenario, if some one can replicate it in e.g. a osboxes.org VirtualBox image that would be useful information.
Reproducible: 1. Download osboxes.org Debian 10 64-bit install for virtualbox. 2. Boot VM. Note that password is provided by osboxes.org, and root has the same password. At this point, will be running a GNOME session. 3. Download Libreoffice 6.4.3 and unzip. 4. Terminal: su root. export PATH="$PATH:/sbin:/usr/sbin". Move to DEBs install folder. dpkg -i *.deb. 5. Terminal: Switch to normal user. 6. Terminal: /opt/libreoffice6.4/program/soffice 7. Create a simple csv file. 8. Close and reopen the CSV file. Import dialog works as expected. Presumably other dialogs do as well but not tested. 9. Adjust software sources to exclude DVD and include the default Debian servers. 10. Terminal: su root. apt-get update. apt-get install xfce4. (At this point I selected LightDM as my manager instead of GDM3, but it presumably does not matter.) 11. Log out, although reboot might be safer. 12. Choose XFCE session and sign in. 13. Terminal: /opt/libreoffice6.4/program/soffice (or open by menu, I was just making absolutely certain I was running the correct version). 14. Open the CSV file. 15. Dialog does NOT work as expected: pressing enter when a dropdown box is selected opens the box instead of closing the dialog. So the issue does have something to do with the desktop environment. GNOME works. XFCE, and apparently Wayland, do NOT work, as per the information provided previously. However, ONLY Libreoffice exhibits this behavior, not any other GTK3 program, under XFCE.
(In reply to bchemnet from comment #33) > So the issue does have something to do with the desktop environment. GNOME > works. Great work on trying to track this down! This is not the correct conclusion. I tested on Ubuntu 20.04 in both xorg and Wayland sessions. Both are GNOME3, and have the bug. What's surprising is that the upstream debs on your Debian box fix it, whereas on my Ubuntu they don't (see comment #22).
is the num lock light on when the problem occurs ? :-)
Caolán: NumLock matters! How weird. But the effect is not (apparently) consistent. On my desktop, I get the bug-reported behavior when NumLock is on (which is my near-constant state), but the expected behavior if I turn it off. However, my laptop exhibits exactly the opposite behavior: the buggy behavior occurs when NumLock is off (the normal state), and the expected behavior when NumLock is on (which I never normally use on my laptop). The behavior is the same for both "Enter" keys.
(In reply to Caolán McNamara from comment #35) > is the num lock light on when the problem occurs ? :-) Caolán, yes, and it disappears when I toggle it off! How on earth could you figure this out? Congrats and a big thanks!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/58981c2d316ffeaf626667fbd2822443588efbed Resolves: tdf#131076 GdkEventKey::state can contain e.g. num lock It will be available in 6.4.5. 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.
it seems likely that the GdkKeyEvent state has extra bits set in the non-working cases so using just the bits that affect ctrl/alt/shift should let an unadorned enter/return do the right thing universally now. Here's hoping.