Bug 97260 - UI: gtk3 keyboard shortcuts not working in all dialog boxes
Summary: UI: gtk3 keyboard shortcuts not working in all dialog boxes
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2016-01-19 21:27 UTC by Luke
Modified: 2016-05-20 20:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

gtk vs gtk3 (56.93 KB, image/png)
2016-01-20 23:42 UTC, Luke
Where to disable automatic mnemonics in dconf-editor (89.15 KB, image/png)
2016-01-23 05:17 UTC, Adolfo Jayme Barrientos

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2016-01-19 21:27:12 UTC
When opening and closing documents, I do everything from the keyboard. But with gtk3, you have to use the mouse to bring the close dialog into focus.

Steps to reproduce:
1. Open a new document
2. Type something 

Expected Results:
1. Save document dialog pops up with "Save" hightlighted

Actual Results:
1. With gtk3, save dialog pops up with nothing highlighted and not in focus
2. With "$ SAL_USE_VCLPLUGIN=gtk ./soffice", it works as expected
Comment 1 Luke 2016-01-20 23:26:42 UTC
I just realized there's two issues going on here.

1) The currently selected button isn't highlighted.
2) The keyboard shortcuts are missing.
Comment 2 Luke 2016-01-20 23:42:57 UTC
Created attachment 122121 [details]
gtk vs gtk3
Comment 3 Maxim Monastirsky 2016-01-21 00:00:26 UTC
(In reply to Luke from comment #1)
> 1) The currently selected button isn't highlighted.
Well, looking at your screenshot _it is_ highlighted (there is a thin orange frame around the save button).

> 2) The keyboard shortcuts are missing.
It's a feature, and how any other gtk3 app work. The shortcuts are hidden until you hold the alt key. See Bug 92630.
Comment 4 Luke 2016-01-21 08:45:24 UTC
> thin orange frame around the save button

On my setup, that line is practically invisible. GKT2 had both the frame and a shaded button. The hightlight/shade is missing. This is a poor UI choice, but wouldn't be an issue for me if it weren't for the 2nd problem.

> It's a feature, and how any other gtk3 app work. The shortcuts are hidden
> until you hold the alt key. See Bug 92630.

The problem is you never used to have to hold ALT+S to save, only press "S", so my muscle memory is broken. This breaks the workflow for seasoned users. The lack of a visible highlight compounds the issue, making it look like the focus has been lost. 

Simon or Caolán,
Can we restore the old behavior to enable dialog box shortcuts to work without pressing alt?
Comment 5 Adolfo Jayme Barrientos 2016-01-22 09:20:06 UTC
Oh no, please no. Let’s not introduce even more convoluted and obscure options for everything.

And for the theme issue, well, you know where to report it: Launchpad.net. We do not develop GTK+ themes.
Comment 6 Luke 2016-01-22 12:31:35 UTC
I'm sorry for confusing things by bringing up two separate issues. I will file a bug report on Launchpad.net for the invisible orange frame issue.

To be clear this report is about:
GTK+ 3 Keyboard Shortcuts Not Working on Dialog Boxes

It is a regression in the gtk3 plugin that breaks users workflow. We shouldn't force users to relearn how do things, hiding the old behavior behind a feature with zero discoverability. 

I bisected this down to: 238575424341dedaef9713fcdb988ed39ccbf82c -> BAD d2cefbe7effbee079c05a5a8234305650618fdc1 -> GOOD

tdf#92630 Enable auto-accelerator behaviour for gtk

Is in that range. It affects all dialog boxes removing the ability to just press a key to use the bottom buttons.
Comment 7 Adolfo Jayme Barrientos 2016-01-23 05:17:00 UTC
> It is a regression in the gtk3 plugin that breaks users workflow

Calling it a “regression” is misleading. A new feature was introduced that made LibreOffice match the GTK+ (default) setting of hiding the accelerators until the Alt key is pressed. Since now LibreOffice matches this default setting of your DE, there is no regression here. Just disable that setting in dconf-editor or the terminal (with the gsettings command), if you’re bothered by it.
Comment 8 Adolfo Jayme Barrientos 2016-01-23 05:17:49 UTC
Created attachment 122170 [details]
Where to disable automatic mnemonics in dconf-editor
Comment 9 Luke 2016-01-24 20:08:18 UTC
You solution is not acceptable. That is a global variable. And we should not force users to make changes like that just to keep the workflow consistent. The GTK3 workflow should be the same as the GTK2 and Windows by default. 

We should only use the accelerators in menu items ONLY.  By using them in the dialog buttons, we force the user to use different shortcuts for differ toolkits.
Ctrl+W, S -> Ctrl+W, Alt+S

This is a bug. Shortcut should not change between widget toolkits.
Comment 10 Simon Long 2016-01-24 21:22:29 UTC
Standard behaviour in GTK applications is that buttons in dialogs with accelerators defined only operate when the shortcut key is pressed along with a modifier; they do not operate when the shortcut key is pressed on its own. LibreOffice may have worked otherwise in the past, but the requirement to press a modifier key to access an accelerator for a dialog button is standard GTK behaviour, not an error.
Comment 11 Simon Long 2016-01-24 22:20:30 UTC
I've also just checked running LO with the GTK plugin disabled (by setting environment variable SAL_USE_VCLPLUGIN to "gen", and this re-enables the use of shortcut keys on dialogs without a modifier key.

So as far as I can see, behaviour of dialog shortcuts is now correct for both non-GTK (no modifier required) and GTK (modified needed) operation of LO.

As my comment above - GTK requires a modifier key for shortcuts, both in dialogs and menus - this is by design and not a bug.
Comment 12 Luke 2016-01-25 00:02:02 UTC
Thank you for the explanation. Is it possible to not use GTK accelerators in the dialog box buttons so that gen, gtk, and windows can all behave the same way? In other words only use accelerators for menus and not dialog boxes?
Comment 13 Simon Long 2016-01-25 06:55:27 UTC
It's possible, but it's the wrong thing to do. The whole point of the GTK plug-in is to make LO both look *and behave* like a GTK application - all GTK applications use modifiers for accelerators in dialogs, as that is the way the toolkit is written; it's how GTK works. If the GTK plug-in is modified to behave as you suggest, while it might indeed mean that LO's behaviour is consistent across all toolkits, it means that LO's behaviour is inconsistent with that of other applications when running on a system based on GTK, which defeats the entire purpose of the plug-in.

Bottom line - you can either have the GTK appearance with the GTK behaviour, or you can turn off the GTK appearance and have the behaviour you want. But the GTK behaviour should not be removed from the GTK appearance - the whole point of the GTK plug-in is to provide consistency in a GTK environment.
Comment 14 Simon Long 2016-01-25 09:03:50 UTC
Just to clarify my comment above, when I say it is possible to do what you want, it involves changing and rebuilding the code - I am not aware of any setting or variable that can be used to achieve the effect you want in an existing LO build.
Comment 15 V Stuart Foote 2016-02-04 21:53:38 UTC
*** Bug 97586 has been marked as a duplicate of this bug. ***