Bug 92866 - Keyboard command shortcuts don't work in start center
Summary: Keyboard command shortcuts don't work in start center
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected) Master
Hardware: Other Linux (All)
: medium normal
Assignee: Caolán McNamara
Whiteboard: target:5.1.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Start-Center Shortcuts-Accelerators
  Show dependency treegraph
Reported: 2015-07-22 07:10 UTC by Matthew Francis
Modified: 2016-08-03 11:08 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2015-07-22 07:10:31 UTC
Seems to be limited to the Start Centre. Works as expected in other components

Steps to reproduce
- Start LibreOffice to the Start Centre
- Ctrl+Q

Expected result
- LO closes

Actual result
- Nothing
Comment 1 Matthew Francis 2015-07-22 07:13:19 UTC
(bisected, so taking the liberty of setting to NEW)

This seems to have begun at the below commit.
Adding Cc: to simon@raspberrypi.org; Could you possibly take a look at this? Thanks

commit 74407aef94b6d8dfdd69891c4a6e578587ef3e71
Author: Simon Long <simon@raspberrypi.org>
Date:   Wed Jul 8 18:02:50 2015 +0100

    tdf#92630 Enable auto-accelerator behaviour for gtk
    Change-Id: I671177dd1f9e535c28a29bcbd6b74f1c789371ea
    Reviewed-on: https://gerrit.libreoffice.org/16883
    Reviewed-by: Caolán McNamara <caolanm@redhat.com>
    Tested-by: Caolán McNamara <caolanm@redhat.com>
Comment 2 V Stuart Foote 2015-07-22 15:45:09 UTC
@Matthew, isn't this a duplicate of bug 92516
Comment 3 Simon Long 2015-07-24 16:18:51 UTC
This can be fixed by modifying the Window::KeyInput function in vcl/source/window/window.cxx - I added code to this to prevent accelerators having any effect when underscores are not shown, and this is preventing the CTRL+combination from being passed through.

However, this seems to me to expose a more fundamental problem with this particular window - its behaviour is non-standard in various ways. First off, CTRL-Q does close any other LO application, so they are clearly handling accelerators and shortcuts differently.

But this window does several odd things. First off, the shortcut keys shown against the file types to create new documents work without any modifier being held down, but they are shown with underscores, which is standard notation for an ALT+<key> combination - is this really desired behaviour? They actually work with any of <key>, ALT+<key> and CTRL+<key> - this cannot be right, surely?

Hitting H on its own is a shortcut for the Help button at the bottom of the screen, as is ALT-H - this is in spite of the fact that there is an underscore on the H of the Help menu at the top of the screen - as far as I can tell, it is not possible to open the Help menu with a keyboard shortcut in spite of it being signalled as possible by the presence of the underscore. This in turn renders the menu behaviour as non-standard.

I also don't understand why the holding down and releasing of the ALT key on this screen does not hide the accelerator underscores, in spite of the code I wrote to do this working perfectly in every other window and dialog in LO.

If you want a quick fix to the problem reported, modify the statement "if (cod.GetCode () >= 0x200 && cod.GetCode () <= 0x219)" in the function above to "if (cod.GetCode () >= 0x200 && cod.GetCode () <= 0x219 && cod.GetModifier () != 0x2000)", which means that CTRL presses override the accelerator tests, but I strongly feel that the correct thing to do is to rewrite the key handling code in this application to work consistently with the rest of the LO interface.
Comment 4 tommy27 2015-07-26 13:24:04 UTC
(In reply to V Stuart Foote from comment #2)
> @Matthew, isn't this a duplicate of bug 92516

you are right. it looks to me the same issue described under Windows.

*** This bug has been marked as a duplicate of bug 92516 ***
Comment 5 tommy27 2015-07-26 13:31:57 UTC
no, wait a moment... it's not the same...

according to comment 0 the "Ctrl+Q" doesn't quits LibO start center under Linux
while it works under Windows if you just click it without entering the "File" menu where the "Ctrl+Q" is uneffective on Windows too... see: https://goo.gl/I51BWI
Comment 6 Simon Long 2015-07-26 15:30:56 UTC
As above - from what I can see, my change has revealed some strange behaviour in the way the Start Centre handles keyboard input; it looks to me as if something is overriding the normal passing of keyboard input through the hierarchy, in which I believe in other applications the menu bar has priority over the rest of the window. The Start Centre was not handling keyboard shortcuts correctly prior to my change; the change has exacerbated the problem by breaking it further, but it looks to me as if the keyboard handling in the Start Centre needs to be revisited and corrected, as it is currently doing something odd. (It may be doing it for perfectly valid reasons, but I've not looked at the code, so I don't know what they are!)
Comment 7 V Stuart Foote 2015-07-26 16:04:51 UTC
I know we'd done some strangeness in making the StartCenter .UI based, but since OS X and WNT don't implement GTK, I'm not surprised a major rework for GTK3 has caused hiccups on non-Linux platforms.

Comment 8 Jan Holesovsky 2015-07-28 11:21:08 UTC
Startcenter has a special hack to make the accelerators like Ctrl+q working, see

BackingWindow::Notify() in sfx2/source/dialog/backingwindow.cxx

It seems that this Notify() is not called any more which is the core of the issue here; but what happened so that the key events do not reach it any more, I have no idea without some real debugging.
Comment 9 Commit Notification 2015-11-06 17:40:40 UTC
Jan Holesovsky committed a patch related to this issue.
It has been pushed to "master":


tdf#92866 startcenter: Make the accellerators work again.

It will be available in 5.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 10 Robinson Tryon (qubit) 2015-12-14 05:16:34 UTC Comment hidden (obsolete)
Comment 11 V Stuart Foote 2016-01-04 17:17:49 UTC
@Kendy, Simon, *

On Windows 8.1 Pro with
Build ID: 4a8c0d313540bd78c9c381edd548b976c580ca9a
CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-04_02:00:52
Locale: en-US (en_US)

When in the Start Center if the main menu has focus the <Ctrl>+Q and <Ctrl>+O shortcuts have no action (Exit or Open dialog respectively).  

But an <F6> or <F10>, or now apparently <Alt> (which is acting like <F10>), key entry to move focus down to the Tab buttons, or to the Thumbnails enables both those global "shortcuts".

Something is still not correct with when shortcuts are enabled or not.
Comment 12 jlerner10 2016-02-01 02:26:25 UTC
Still unable to Exit LO using File - Exit.

I can Exit using Ctrl Q - click the "x" but no other way.

Build ID: 5e3e00a007d9b3b6efb6797a8b8e57b51ab1f737
CPU Threads: 2; OS Version: Windows 6.1; UI Render: default; 
Locale: en-US (en_US)
Comment 13 Caolán McNamara 2016-08-03 11:08:42 UTC
In Comment #3 "holding down and releasing of the ALT key on this screen does not hide the accelerator underscores" is resolved bug #99324. The aspects around duplicate accelerators shown in the backing window and the menubar seems to have been hacked around in the interim with changing accelerators so there isn't duplicates by default. Its probable there's still some dubiousness in there somewhere.

In Comment #5, depending on the way you read it, there might be a suggestion that ctrl+q doesn't work when the file menu is open. That's expected behaviour.

Comment #12 is probably bug #92516

Comment #0 was start center and ctrl+q under linux and probably resolved by kendy's original fix. It definitely works in 5-1 under Linux gen/gtk/gtk3

I'm fairly satisfied that Comment #0 is fixed by the commit of Comment #9. Some of the other aspects are resolved via #92516 and #99324. If there are remaining aspects please split them up as new bugs.