Bug 131076 - UI: Text import dialogue default focus is 'Character set' instead of 'OK'
Summary: UI: Text import dialogue default focus is 'Character set' instead of 'OK'
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.1.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.0.0 target:6.4.3 target:6.4.5
Keywords:
: 132828 (view as bug list)
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2020-03-02 17:19 UTC by John Hills
Modified: 2020-05-19 08:22 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Hills 2020-03-02 17:19:50 UTC
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
Comment 1 Ming Hua 2020-03-02 19:27:53 UTC
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?
Comment 2 John Hills 2020-03-03 08:42:22 UTC
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?
Comment 3 Ming Hua 2020-03-03 13:02:48 UTC
(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.
Comment 4 John Hills 2020-03-03 13:30:02 UTC
Setting the environment variable SAL_USE_VCLPLUGIN to gen (force X11) does solve this issue, so I guess this issue is related to GTK.
Comment 5 bchemnet 2020-03-04 02:56:58 UTC
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.
Comment 6 Caolán McNamara 2020-03-04 09:30:04 UTC
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
Comment 7 Commit Notification 2020-03-04 11:46:22 UTC
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.
Comment 8 Caolán McNamara 2020-03-04 12:02:08 UTC
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
Comment 9 John Hills 2020-03-08 20:25:04 UTC
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'
Comment 10 Caolán McNamara 2020-03-09 08:58:43 UTC
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
Comment 11 Adolfo Jayme 2020-03-09 14:21:51 UTC
> […] who knows when […]

This is when, FWIW: https://wiki.documentfoundation.org/ReleasePlan#7.0_release
Comment 12 Commit Notification 2020-03-17 10:29:49 UTC
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.
Comment 13 Ming Hua 2020-05-08 11:42:56 UTC
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.
Comment 14 bchemnet 2020-05-08 12:07:37 UTC
This bug is not fixed in either the stock 6.4.3 nor in Debian's current release.  Focus is still character set.
Comment 15 Ming Hua 2020-05-08 12:17:14 UTC
(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?
Comment 16 Ming Hua 2020-05-08 12:19:44 UTC
*** Bug 132828 has been marked as a duplicate of this bug. ***
Comment 17 Caolán McNamara 2020-05-08 14:04:00 UTC
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.
Comment 18 John Hills 2020-05-08 14:12:57 UTC
I can confirm that this bug is fixed in 6.4.3.2 from on Debian buster-backports
Comment 19 bchemnet 2020-05-08 14:17:21 UTC
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.
Comment 20 bchemnet 2020-05-08 14:23:31 UTC
Correction: Debian is also 6.4.3.2.
Comment 21 Ming Hua 2020-05-08 14:33:16 UTC
(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?
Comment 22 Marco van Zwetselaar 2020-05-08 14:40:31 UTC
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
Comment 23 Caolán McNamara 2020-05-08 16:20:36 UTC
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.
Comment 24 bchemnet 2020-05-08 16:39:41 UTC
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.
Comment 25 Ming Hua 2020-05-08 16:48:42 UTC
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.
Comment 26 bchemnet 2020-05-08 16:52:26 UTC
No change.  The two are different opcodes (36 & 104 on my desktop), but have the same behavior.
Comment 27 bchemnet 2020-05-08 16:56:35 UTC
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?
Comment 28 Marco van Zwetselaar 2020-05-09 21:16:19 UTC
Another check here: running in a Wayland session makes no difference either.
Comment 29 Marco van Zwetselaar 2020-05-09 21:46:41 UTC
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.
Comment 30 bchemnet 2020-05-09 22:02:12 UTC
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.
Comment 31 Marco van Zwetselaar 2020-05-09 23:20:01 UTC
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?
Comment 32 Caolán McNamara 2020-05-15 10:01:59 UTC
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.
Comment 33 bchemnet 2020-05-15 20:25:36 UTC
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.
Comment 34 Marco van Zwetselaar 2020-05-16 21:45:55 UTC
(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).
Comment 35 Caolán McNamara 2020-05-17 18:19:48 UTC
is the num lock light on when the problem occurs ? :-)
Comment 36 bchemnet 2020-05-17 18:50:38 UTC
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.
Comment 37 Marco van Zwetselaar 2020-05-17 21:24:42 UTC
(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!
Comment 38 Commit Notification 2020-05-18 21:40:10 UTC
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.
Comment 39 Caolán McNamara 2020-05-19 08:22:47 UTC
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.