Confirmed using LO 6.1 beta2 & 6.0.0.3 / Windows 7.
Works fine in LO 5.4.0.3.
=> regression

Very likely related to the revert of the original commit in bug 95761.

Note that using Ctrl-Alt as a keyboard shortcut modifier in Windows is a bad idea, see: https://blogs.msdn.microsoft.com/oldnewthing/20040329-00/?p=40003

I can't reproduce it in

Version: 6.2.0.0.alpha0+
Build ID: 6fcc60b49215acb28edac46bb605767840abd122
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-17_00:25:35
Locale: es-ES (es_ES); Calc: group threaded

nor in

Version: 6.2.0.0.alpha0+
Build ID: 370a30b6acc5b99b6046440f6b5f4f3f5f9f4b1a
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

(In reply to Aron Budea from comment #1)
> Note that using Ctrl-Alt as a keyboard shortcut modifier in Windows is a bad
> idea, see: https://blogs.msdn.microsoft.com/oldnewthing/20040329-00/?p=40003

Well, good to know this. Yet: Word uses Ctrl-Alt-M :).

Maybe we could set a different default for the Comment command. 

Also we might gradually phase out default Ctrl-Alt-* shortcuts - fortunately there is only a handful of these around:

Ctrl-Alt-E - Extension Manager (LO)
Ctrl-Alt-C - Comment (Writer, Calc, Impress, Draw, Web, Form Editor)
Ctrl-Alt-Up/Down - Move up/Down (Writer, Web, Form Editor) - On my Win 8.1, these turn the screen content orientation upside down, instead of moving a bulleted/numbered list item up/down.
Ctrl-Alt-PgUp/PgDown - Previous / Next comment (Impress)

UX team, what do you think?

Created attachment 144368 [details]
Effect of pressing Ctrl-Alt-Down on Windows 8.1 in a bulleted list in LO

(In reply to Gabor Kelemen from comment #3)
> Well, good to know this. Yet: Word uses Ctrl-Alt-M :).

Coherence with MSO sounds like a plan.

> Also we might gradually phase out default Ctrl-Alt-* shortcuts

We do not have enough single-key shortcuts for all commands. An alternative would be to go with ctrl+alt+m on Windows but +c on Linux, meaning our app behaves differently between OS's.

In bug 108892 we went with WFM, bug 99167 with NAB, in bug 97945 some weirdness was closed quickly, bug 43800 about C = Ć points to bug 36588, which got closed as NAB likewise bug 71237.

So perhaps we stick to this position and blame other apps to block the shortcut (depending on what is installed and what language is set up).

(In reply to Heiko Tietze from comment #5)
> (In reply to Gabor Kelemen from comment #3)
> > Well, good to know this. Yet: Word uses Ctrl-Alt-M :).
> 
> Coherence with MSO sounds like a plan.

In Excel, this is Shift+F2. In PowerPoint, there is no shortcut for the comment feature.
Currently LO is coherent with itself, this might have a bit of value.

> 
> > Also we might gradually phase out default Ctrl-Alt-* shortcuts
> 
> We do not have enough single-key shortcuts for all commands. An alternative
> would be to go with ctrl+alt+m on Windows but +c on Linux, meaning our app
> behaves differently between OS's.
> 

It already behaves differently: works on Linux/Mac, but does not work on Win.

Working on Win with a different shortcut would be an improvement here.

Also having a single key shortcut is not necessarily a must - our users could live with Ctrl - Shift - Something too *if that one works reliably*.

For example Ctrl - Shift - C is not used in the main apps at all. But anything like that could work.

> In bug 108892 we went with WFM, bug 99167 with NAB, in bug 97945 some
> weirdness was closed quickly, bug 43800 about C = Ć points to bug 36588,
> which got closed as NAB likewise bug 71237.

For me this number of bugs is an indication that something needs to be done.

> 
> So perhaps we stick to this position and blame other apps to block the
> shortcut (depending on what is installed and what language is set up).

This approach would surely work - in getting me fired from my job and killing our little migration project, that is :).

(In reply to Gabor Kelemen from comment #6)
> Currently LO is coherent with itself, this might have a bit of value.

Yes that was by design when the shortcuts were assigned to <Ctrl><Alt>+C

...
> 
> It already behaves differently: works on Linux/Mac, but does not work on Win.
> 

No, it also functions correctly on Windows installs, but admittedly there can be conflicts with OS where Deadkeys and AltGr mappings are also present.

...

> Working on Win with a different shortcut would be an improvement here.
> 

No, believe the <Ctrl><LeftAlt>+C works correctly on Windows 10 in all locales, so the Shortcut could be tightened up to distinguish between Left/Right Alt key. 

Similar locale issues with the <Alt>+X Unicode toggle and conflict with Deadkey and AltGr mappings, many of those had to be addressed by altering the assigned shortcut for specific locales--same _could_ be done here, but leave the otherwise functional default/documented <Ctrl><Alt>+C comment in place.

(In reply to Gabor Kelemen from comment #3)
> (In reply to Aron Budea from comment #1)
> > Note that using Ctrl-Alt as a keyboard shortcut modifier in Windows is a bad
> > idea, see: https://blogs.msdn.microsoft.com/oldnewthing/20040329-00/?p=40003
> 
> Well, good to know this. Yet: Word uses Ctrl-Alt-M :).
I don't care about what Word uses, I would like to avoid the mess we had in LO with bug 97908 / bug 100908 & duplicates.

(In reply to V Stuart Foote from comment #7)
> No, it also functions correctly on Windows installs, but admittedly there
> can be conflicts with OS where Deadkeys and AltGr mappings are also present.
Functions correctly and having conflicts sounds the opposite to me. My experience is that it functions correctly with English - US keyboard layout, but not with English - US International. You could say it's not broken in Windows in general, that's true.

> No, believe the <Ctrl><LeftAlt>+C works correctly on Windows 10 in all
> locales, so the Shortcut could be tightened up to distinguish between
> Left/Right Alt key. 
It doesn't depend on locale, but on keyboard layout, and I have doubts the shortcut works with Left Alt all the time. I don't have Windows 10 at hand, but with Windows 7 it doesn't.

Considering the previous failed attempt at fixing such keyboard shortcuts that resulted in broken key combinations, I would find the safest to avoid all Ctrl + Alt shortcuts as primary ones (I'm fine with leaving the current shortcuts as legacy ones for keyboard layouts where they worked).

There's a very clear distinction between phasing out Ctrl + Alt shortcut combinations or trying to make them work somehow:
Phasing them out requires no programming effort, and has no chance of introducing regressions plaguing different non-US keyboard layouts.

* The issue seems to be elusive (comment 2)
  + If it is a regression (comment 1) we should fix the bug.
* Shortcuts are rare and we need combinations - or don't have shortcuts for many functions.
  + Adding comments is an important function but only for documents in review.
* The current shortcut is well-known for LibreOffice users and changing it to something similar (Ctrl+Alt+ C -> M) is wrong for more users than solving an issue for some.

From the UX POV I recommend to not change the shortcut and solve the bug, if there one. Up to QA now.

Thanks for your assessment, Heiko.

I have checked that this behavior occurs between versions 3.3.0 to 5.0.0 and since 6.0.0, and was reintroduced with the revert of bug 95761's commit. Considering the problems with that commit, I'm removing regression-related keywords, but if anyone is interested in taking a stab at the issue, feel free to use that as reference.

shouldn't it be localization teams that lead the dance here?
They get most of the question too, I think :)

Gabor Kelemen committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/6aff7fe6d5a02f44ec43e63672ae56166f9b9cb6%5E%21

tdf#118269 Replace InsertAnnotation commands accel for Hungarian only

It will be available in 6.3.0.

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

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