Bug 38891 - Ctrl+Alt+? shortcuts don't work on some keyboard layouts
Summary: Ctrl+Alt+? shortcuts don't work on some keyboard layouts
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: medium major
Assignee: Not Assigned
Depends on:
Blocks: Shortcuts-AltGR
  Show dependency treegraph
Reported: 2011-07-01 08:43 UTC by khagaroth
Modified: 2021-05-13 13:38 UTC (History)
7 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description khagaroth 2011-07-01 08:43:42 UTC
Default use of Ctrl+Alt+? shortcuts (where ? is any key) breaks keyboard input in some locales. This combination is used to input characters, that are not directly accessible from the keyboard (\|[]{}<>#&$@).

On Czech keyboard, for example, the shortcut Ctrl+Alt+F (Find and replace introduced in 3.4) is used to enter '[', Ctrl+Alt+C is '&' and so on. The same very likely applies to other keyboard layouts.
Comment 1 Rainer Bielefeld Retired 2011-07-01 11:07:37 UTC
That means:
 Expected (general Czech use): Ctrl+Alt+F types "["
 Actual LibO 3.4.1 CZ:  Ctrl+Alt+F brings up 'Search and Replace' dialog

Your WIN version? WIN Localization?, LibO UI localization?
Comment 2 khagaroth 2011-07-01 12:01:11 UTC
Looks like I messed up, as I didn't notice that my keyboard layout switched to EN-US, that's why I couldn't input any of those extra characters.

So the real bug is actually the opposite of previously reported, as after switching to Czech layout (double checked this time), I can input the special characters, but I can't open the 'Search and replace' dialog (changed the summary accordingly). 

The conclusion is still the same, Ctrl+Alt+? shortcuts shouldn't be used, as they are not guaranteed to work on all keyboard layouts.

(Czech Windows 7, Czech LibO localization, but the behavior depends on the keyboard layout, not on the software localization)
Comment 3 Jeff 2011-08-09 06:13:36 UTC

Reproduce on FrenchUI, with a keyboard's driver for specials characters.

With this special keyboard's driver, AltGr+F give "

With 3.4.2, Ctrl+Alt+F give " too.

No problem wiht default keyboard's driver.

It's possible to differentiate AltGr and Ctrl+Alt ?
Comment 4 Olivier R. 2011-08-11 00:37:07 UTC
I confirm the bug.

Ctrl+Alt is the equivalent of AltGr which modifies often the behavior of keyboard layouts.

The shortcut Ctrl+Alt+F should be replaced by Ctrl+H, which opens the "search and replace" dialog box on many applications, like:
- Microsoft Office
- Notepad++
- PsPad
Comment 5 khagaroth 2011-11-20 02:02:52 UTC
Posting just to get this CCd to kendy as he was the one working on the Findbar.
Comment 6 GerardF 2011-11-20 13:46:58 UTC
Find & Replace is now opened with Ctrl+H in Master.

I don't know if other Ctrl+Alt+Key need to be changed.
If not, this issue can be closed.
Comment 7 khagaroth 2011-11-21 01:39:27 UTC
Only other Ctrl+Alt shortcut that I know of is Ctrl+Alt+C. That should be replaced too and if there are any other then they should be replaced as well. Look at http://en.wikipedia.org/wiki/AltGr_key, there basically isn't any safe Ctrl+Alt shortcut on Windows, where Ctrl+Alt == AltGr.
Comment 8 Andras Timar 2011-11-21 06:07:52 UTC
(In reply to comment #7)
> Only other Ctrl+Alt shortcut that I know of is Ctrl+Alt+C. That should be
> replaced too and if there are any other then they should be replaced as well.
> Look at http://en.wikipedia.org/wiki/AltGr_key, there basically isn't any safe
> Ctrl+Alt shortcut on Windows, where Ctrl+Alt == AltGr.

Ctrl+Alt+C is for Insert Comment, a rarely used function. The problem is that there are more functions than good shortcuts. Also, I saw many Ctrl+Alt+Shift+? in officecfg/registry/data/org/openoffice/Office/Accelerators.xcu. In theory we should change those, too.
Comment 9 Björn Michaelsen 2011-12-23 12:25:21 UTC Comment hidden (obsolete)
Comment 10 khagaroth 2011-12-23 13:01:37 UTC
Three posts back someone fixed the shortcut for Find and replace (changed it to Ctrl+H), so thats now fixed in 3.5.
But this bug still applies for any current or future introduced Ctrl+Alt+? shortcut. Any such key combination is simply unusable on many keyboard layouts in Windows.
This bug could be possibly closed, because the original reason for this report was fixed, but someone should decide what to do with this limitation, there is no workaround and if LO starts using these shortcuts, half of them (and on some keyboards even more) won't work.
Comment 11 QA Administrators 2015-07-18 17:44:49 UTC Comment hidden (obsolete)
Comment 12 Rogerio Luz Coelho 2015-10-12 15:12:36 UTC
This is a bug since Ooo. 

Every entry in the functions table for Windows that has a shortcut that starts with CTRL+ALT should be changed to one with ALT+SHIFT. 

This makes it virtually impossible for Windows keymaps to send the caracter instead of the function to LibO. 

The ENG-ITL keyboard used in many countries constructs CTRL+ALT as ALTGR so we get a mess in documentation of the shortcut funtions for LibO. 

For example a generally used function such as Comment is supposed to be used by CTRL+ALT+C but what this does (even now in Firefox) is the "©" character. 

This is a major bug because it is a MAJOR pain in the ***  to explain to newcomers on the help lists why this behavious is obvious in Windows boxes. 

Comment 13 Juergen Funk (CIB) 2015-12-17 21:30:15 UTC
Look to tdf#95761
Comment 14 QA Administrators 2018-04-19 02:34:20 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2020-04-19 03:36:10 UTC
Dear khagaroth,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team