Bug 110452 - Alt+key shortcut assigned to a command that is used as a menu mnemonic opens the menu
Summary: Alt+key shortcut assigned to a command that is used as a menu mnemonic opens ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Caolán McNamara
QA Contact:
URL:
Whiteboard: target:6.0.0 target:5.4.2
Keywords: bibisected, regression
Depends on:
Blocks: GTK3
  Show dependency treegraph
 
Reported: 2017-07-31 08:40 UTC by rolfofsaxony
Modified: 2017-09-15 14:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
screen shot of the Alt+T behaviour when assign to Underline (86.34 KB, image/png)
2017-08-22 11:17 UTC, rolfofsaxony
Details
bibisect details (2.40 KB, text/plain)
2017-09-01 01:10 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rolfofsaxony 2017-07-31 08:40:22 UTC
Unable to reassign an Alt+key to a macro that is used as a menu mnemonic.
Upgraded from 5.1.x.x to 5.4.0.3
I used to be able to assign Alt+T (amongst others) for example, to a macro.
Under 5.4.0.3 this no longer works properly.
Now both events occur.
The Menu->Tools is selected AND the macro fires, leaving the Menu->Tools open and having to be closed manually.
Comment 1 rolfofsaxony 2017-07-31 16:46:28 UTC
If this behaviour is retained we can wave goodbye to being able to reassign
Alt F, E, V, I, O, S, A, T, W and H
In which case they should not be offered as options in 
Tools->Customise->Keyboard
Comment 2 Buovjaga 2017-08-21 16:11:03 UTC
No problem for me assigning Alt-T as a macro mnemonic.

Do you also have the problem with any other function and not just macros?

Arch Linux 64-bit, KDE Plasma 5
Version: 6.0.0.0.alpha0+
Build ID: 668ab2e739397e6b095372a1a468bd4f515927b6
CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on August 20th 2017
Comment 3 rolfofsaxony 2017-08-22 09:37:25 UTC
(In reply to Buovjaga from comment #2)
> No problem for me assigning Alt-T as a macro mnemonic.
> 
> Do you also have the problem with any other function and not just macros?
> 
> Arch Linux 64-bit, KDE Plasma 5
> Version: 6.0.0.0.alpha0+
> Build ID: 668ab2e739397e6b095372a1a468bd4f515927b6
> CPU threads: 8; OS: Linux 4.12; UI render: default; VCL: kde4; 
> Locale: fi-FI (fi_FI.UTF-8); Calc: group
> Built on August 20th 2017

I am able to assign a macro to Alt-T and any other character that is used as a "Alt menu shortcut" (F,E,V, etc). The issue was that not only does the macro fire up but that the Alt Menu event fired as well. So "hotkey" assignment of the macro was not overriding the menu shortcut as it did previously. Instead both occurred.
The result was that the macro ran happily but the Alt menu selection was left live and had to be cancelled.
This behaviour was a show stopper for me, I removed LO 5.4.0.3 (the offending version) and reverted back to Build ID: 1:5.1.6~rc2-0ubuntu1~xenial2, where reassigning an Alt menu character to a macro "replaces" the Alt menu function.
Comment 4 Buovjaga 2017-08-22 09:50:49 UTC
(In reply to rolfofsaxony from comment #3)
> I am able to assign a macro to Alt-T and any other character that is used as
> a "Alt menu shortcut" (F,E,V, etc). The issue was that not only does the
> macro fire up but that the Alt Menu event fired as well. So "hotkey"
> assignment of the macro was not overriding the menu shortcut as it did
> previously. Instead both occurred.

Yeah, no such problem for me on Linux or Windows.

Yet, you did not answer my question about if this is restricted to macros or also affects any shortcuts.

Win 7 Pro 64-bit, Version: 5.4.0.3 (x64)
Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
CPU threads: 4; OS: Windows 6.1; UI render: default; 
Locale: fi-FI (fi_FI); Calc: CL
Comment 5 Buovjaga 2017-08-22 09:57:45 UTC
Could you try with this master build, then you do not have to install anything: http://dev-builds.libreoffice.org/daily/master/Linux-archive-x86_64@80-updater/current/LibreOfficeDev_6.0.0.0.alpha0_Linux_x86-64_archive.tar.gz

You just run the soffice binary in the program/ directory after unpacking.
Comment 6 rolfofsaxony 2017-08-22 10:02:41 UTC
(In reply to Buovjaga from comment #4)
> (In reply to rolfofsaxony from comment #3)
> > I am able to assign a macro to Alt-T and any other character that is used as
> > a "Alt menu shortcut" (F,E,V, etc). The issue was that not only does the
> > macro fire up but that the Alt Menu event fired as well. So "hotkey"
> > assignment of the macro was not overriding the menu shortcut as it did
> > previously. Instead both occurred.
> 
> Yeah, no such problem for me on Linux or Windows.
> 
> Yet, you did not answer my question about if this is restricted to macros or
> also affects any shortcuts.
> 
> Win 7 Pro 64-bit, Version: 5.4.0.3 (x64)
> Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c
> CPU threads: 4; OS: Windows 6.1; UI render: default; 
> Locale: fi-FI (fi_FI); Calc: CL

Yes, sorry. As I said, it was a show stopper, so I stopped and did not test any further.
I shall give the build that you have linked to a whirl and get back to you, when I can.
Regards
Comment 7 rolfofsaxony 2017-08-22 11:17:21 UTC
Created attachment 135724 [details]
screen shot of the Alt+T behaviour when assign to Underline
Comment 8 rolfofsaxony 2017-08-22 11:24:56 UTC
Tested Version: 6.0.0.0.alpha0+
Build ID: 0e35b7738d9f276c0566df0f2cc0f1eed7900d6c

It displays the same behaviour for macros (python) both in an extension and standalone in the Scripts/python directory.
I re-assigned Ctrl-U Underline to Alt-T and it behaves in the same way.
The selected text is underlined AND the Tools Menu event fires. I added a screen shot.
The same behaviour was observed when re-assigning Ctrl+I Italic to ALt+V although, obviously, the selected text turned to Italic and the View Menu was left on the screen.
Comment 9 rolfofsaxony 2017-08-22 13:39:19 UTC
Additionally:
Setting 
org.openoffice.VCL:ConfigurableSettings['Menu'] SuppressAccelerators string true

Does not appear to make any difference. Accelerators are still active when the Alt key is pressed
Comment 10 Maxim Monastirsky 2017-08-22 14:36:14 UTC
Confirmed with gtk3. No problem with gtk or gen.
Comment 11 Terrence Enger 2017-09-01 01:10:49 UTC
Created attachment 135919 [details]
bibisect details

Working on debian-stretch in the linux dbgutil daily till52
repository, I see that the bug came in somewhere in the 49 commits:

          commit    date        s-h
          --------  ----------  --------
    good  a441153e  2016-02-26  49f81b3f
    bad   4c8042c3  2016-02-27  af57a81d

I am removing keyword bibisectRequest and adding bibisected.
Comment 12 Terrence Enger 2017-09-01 01:17:54 UTC
I should have mentioned ... This is with xfce desktop, and I see the
bug with SAL_USE_VCLPLUGIN=gtk3 but not with gen.
Comment 13 Caolán McNamara 2017-09-04 11:07:07 UTC
We should be able to use the return code of the keyboard callback to determine if we've used the keystroke in libreoffice and suppress the native menu bar from seeing it
Comment 14 Commit Notification 2017-09-04 12:29:38 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3266c3bf545cc3045f843f764b4c420241d9e4da

Resolves: tdf#110452 stop menubar processing Alt+foo if handled by core widget

It will be available in 6.0.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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Terrence Enger 2017-09-05 13:32:32 UTC
I see the bug fixed on debian-stretch with xfce desktop in daily Linux
dbgutil bibisect repository version 2017-09-05.
Comment 16 rolfofsaxony 2017-09-06 07:11:29 UTC
(In reply to Terrence Enger from comment #15)
> I see the bug fixed on debian-stretch with xfce desktop in daily Linux
> dbgutil bibisect repository version 2017-09-05.

Is there a build in the daily builds that I can test.
I installed the latest from 2017/09/05 but there is something awry with the python, as it can not find its libraries, complaining about no encodings.
Comment 17 Terrence Enger 2017-09-06 13:37:50 UTC
(In reply to rolfofsaxony from comment #16)
> Is there a build in the daily builds that I can test.
> I installed the latest from 2017/09/05 but there is something awry with the
> python, as it can not find its libraries, complaining about no encodings.

Did you follow the instructions at "Installing in parallel/Linux"
<https://wiki.documentfoundation.org/Installing_in_parallel/Linux>?

Perhaps it would be worth-while to try another daily build.  Then take
take your problem to the QA mailing list, including the error message
that is stopping you.

I wish I could give you more substantive help.

Terry.
Comment 18 Commit Notification 2017-09-15 14:50:56 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=aaa6ceb9fa91f38d1c32cfe3882255cfd1490ab9&h=libreoffice-5-4

Resolves: tdf#110452 stop menubar processing Alt+foo if handled by core widget

It will be available in 5.4.2.

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.