Bug 138225 - Menu shortcuts using ALT always use the default keyboard layout, not the selected layout
Summary: Menu shortcuts using ALT always use the default keyboard layout, not the sele...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2020-11-15 02:09 UTC by harrisonhopkins
Modified: 2023-12-13 03:14 UTC (History)
1 user (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 harrisonhopkins 2020-11-15 02:09:39 UTC
Description:
When using LibreOffice on Fedora 32/33, if the user has multiple keyboard layouts enabled, the menu shortcuts using ALT always use the default keyboard layout.





Steps to Reproduce:
1. Use Fedora 33 or 32 with Wayland (default 33 distribution)
2. Open Settings
3. Switch to "Region and Language" tab
4. Add an additional keyboard layout (Click the '+' under "Input Sources", select 'English (United States)', select "English (Colemak)" to replicate my exact setup)
5. Open LibreOffice (Writer and Calc both tested)
6. Change your input layout to the one you added in step 4
7. Attempt to use a keyboard shortcut that is /not/ in the same position as in the first keyboard layout (QWERTY in my example)

Actual Results:
The keyboard shortcut is sent as if you were in the first keyboard layout (QWERTY)

Expected Results:
The keyboard shortcut is sent as if you were in the second keyboard layout (QWERTY)


Reproducible: Always


User Profile Reset: No



Additional Info:
Version info:
Version: 7.0.3.1
Build ID: 00(Build:1)
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

This issue is localized to LibreOffice. Other apps do not have this problem.
Comment 1 Stéphane Guillou (stragu) 2023-05-15 16:23:53 UTC
Than you for the report.

Are you still having this issue in a recent version like LO 7.5?

I just tested in 7.5.3.2 and could not reproduce: with my German keyboard layout, I launch LO and Ctrl + Q closes LO as expected. I open LO again, switch my layout to French, and using the same key results in a select all action (Ctrl + A). So working as expected.

Using Ubuntu 20.04 with GNOME 3.36.8 + Wayland and:

Version: 7.5.3.2 (X86_64) / LibreOffice Community
Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 2 QA Administrators 2023-11-12 03:13:25 UTC Comment hidden (obsolete)
Comment 3 QA Administrators 2023-12-13 03:14:06 UTC
Dear harrisonhopkins,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp