Bug 76096 - Application window keybindings (key strokes) not executed in some contexts
Summary: Application window keybindings (key strokes) not executed in some contexts
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2014-03-13 04:42 UTC by Tim Lloyd
Modified: 2019-09-26 05:34 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
make this work for this specific widget (1.11 KB, patch)
2019-09-08 16:22 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Lloyd 2014-03-13 04:42:18 UTC
After opening a writer (or calc) document I normally exit the by hitting CTRL-W. All good.

I open a writer (or calc) document. Press CTRL-F to search for text, enter the text string and then press ENTER.
I then press CTRL-W to exit - no action. 
I take the mouse out of the search box and into the text and click anywhere
I then press CTRL-W and can exit the file.

I was expecting to be able to exit at any time, not just with the cursor in the text.

Fedora 20/LO4.2.1.1

This "feature" also exists in Windows XP LO4.2.04
Comment 1 Jean-Baptiste Faure 2014-03-13 05:22:00 UTC
Yes, we have the same behavior when the focus is not in the text window, for example in the Navigator. 
Already reproducible in version 4.1.5. Same behavior with ctrl+Q to quit the application.

Not sure if we should consider that as a bug, added UX-advise in CC.

Best regards. JBF
Comment 2 Stefan Knorr (astron) 2014-03-13 09:55:14 UTC
(In reply to comment #1)
> Not sure if we should consider that as a bug, added UX-advise in CC.

Tim's issue sounds like a bug to me.

The issue with the Navigator is a bit more tricky since the Navigator has an own (palette) window. But still, I think, per main-window key bindings should be respected wherever the focus is (within the window and its palette windows) unless they collide with a key binding for the current element. (In that case, the key binding for the element should take precendence.)

Palette windows are also main-window specific, i.e. they don't become another main window's subwindow when focus changes from one main window to another. So this should be no problem to implement.
Comment 3 Joel Madero 2015-05-02 15:40:57 UTC Comment hidden (obsolete)
Comment 4 Tim Lloyd 2015-05-03 07:49:12 UTC
this problem is still occurring in both writer and calc. Fedora 22.

Version: 5.0.0.0.alpha1
Build ID: 77a35997fa7cff387b5b135ff0c42155f80e9884
Locale: en_AU
Comment 5 QA Administrators 2016-09-20 09:36:47 UTC Comment hidden (obsolete)
Comment 6 Jean-Baptiste Faure 2016-09-25 16:58:25 UTC
Still reproducible in LO 5.2.3.0+ and current master, both built at home under Ubuntu 16.04 x86-64.

Best regards. JBF
Comment 7 Xisco Faulí 2017-09-29 08:48:13 UTC Comment hidden (obsolete)
Comment 8 Jean-Baptiste Faure 2017-10-28 08:27:58 UTC
Still reproducible in LO 5.4.4.0.0+ built at home under Ubuntu 16.04 x86-64.

Best regards. JBF
Comment 9 QA Administrators 2018-10-29 03:58:27 UTC Comment hidden (obsolete)
Comment 10 Jean-Baptiste Faure 2019-01-06 19:26:39 UTC
Still reproducible in LO 6.2.0.1.0+ under Ubuntu 18.04.

Best regards. JBF
Comment 11 Thomas Lendo 2019-09-08 07:14:16 UTC
Adding needsUXEval as it was asked for in 2014.
Comment 12 Heiko Tietze 2019-09-08 08:12:06 UTC
Caolan, can we change this at all without explicitly binding generic keys for every single widget?
Comment 13 V Stuart Foote 2019-09-08 13:14:15 UTC
Have to admit, I get a bit confused between shortcuts assigned in VCL [1] vs. shortcuts assigned to .uno actions as accelerators [2], and which actually assert, and where used, in the UI. It seems like the usage has drifted apart.

The mishandling of the Q_MOD1 (<Ctrl>+Q) assigned .uno:Quit action is see also bug 97511

=-ref-=
[1] https://opengrok.libreoffice.org/xref/core/vcl/source/window/keycod.cxx?r=55402d82#37
[2] https://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Office/Accelerators.xcu?r=6607e291#222
Comment 14 Caolán McNamara 2019-09-08 16:21:33 UTC
You can just hit esc a few times and then ctrl+w.

The general scheme of things is that the handling of an event bubbles up from the target widget so if not handled by it the event is passed to the parent to have a go. Don't really know if that's the case here or not.

FWIW the same will happen if you put the focus in e.g. the fontname widget in the standard toolbar.

I'll attach a hackaround for this one specific case if someone else want to take it and run with it.
Comment 15 Caolán McNamara 2019-09-08 16:22:16 UTC
Created attachment 154023 [details]
make this work for this specific widget
Comment 16 Cor Nouws 2019-09-24 19:42:26 UTC
Indeed, this happens in many places.
E.g. Ctrl+W if focus is in Navigator.. nope.

Questen is: is it fine to imrove some situations and have the rest (hard to fix, or unknown) untouched?
Comment 17 Heiko Tietze 2019-09-26 05:34:59 UTC
Let's apply Caolan's patch(es) situation-dependent. Basically the fizzing events should work but I'm not sure that alt+f4 or ctrl+w needs to work in every context.