Reproducible on LibreOffice 6.3.1.0+ built at home under Ubuntu 18.04 x86-64.

In my case, the actual results is nothing, this key combination does nothing.

Best regards. JBF

(In reply to Xisco Faulí from comment #2)
> 
> Does it happen if you launch LibreOffice from commandline using
> 'SAL_USE_VCLPLUGIN=gtk3 soffice' ?

The shortcut works fine when setting this env variable

(In reply to Xisco Faulí from comment #2)
> [...]
> Does it happen if you launch LibreOffice from commandline using
> 'SAL_USE_VCLPLUGIN=gtk3 soffice' ?

I already use the plugin GTK3 and it does not work with any version I can test : 6.1, 6.2, 6.3 and master.
Could it be possible that the problem is linked to the use of an AZERTY keyboard?

Best regards. JBF

I cannot reproduce on Debian testing with KDE Plasma, German keyboard layout:

Version: 6.4.0.0.alpha0+
Build ID: fa774e16b1dfe4844ec5eb3f9372d6468f6b8a56
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kf5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

neither with the package provided in Debian testing (libreoffice 1:6.3.0-2):

Version: 6.3.0.4
Build ID: 1:6.3.0-2
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded


@Martin: What is your keyboard layout that works with SAL_USE_VCLPLUGIN=gtk3, but not with the "kde5" VCL plugin?

(In reply to Jean-Baptiste Faure from comment #4)
> I already use the plugin GTK3 and it does not work with any version I can
> test : 6.1, 6.2, 6.3 and master.
> Could it be possible that the problem is linked to the use of an AZERTY
> keyboard?

That's possible. Can you try whether it works as expected when you configure another keyboard layout?

(In reply to Michael Weghorn from comment #5)
> 
> @Martin: What is your keyboard layout that works with
> SAL_USE_VCLPLUGIN=gtk3, but not with the "kde5" VCL plugin?
> 

Hi Michael,

I tested for polish ( pl ) and english ( us ). In both cases the issue goes away when I run libreoffice using the above mentioned env variable.

Cheers

(In reply to Martin from comment #6)
> (In reply to Michael Weghorn from comment #5)
> > 
> > @Martin: What is your keyboard layout that works with
> > SAL_USE_VCLPLUGIN=gtk3, but not with the "kde5" VCL plugin?
> > 
> 
> Hi Michael,
> 
> I tested for polish ( pl ) and english ( us ). In both cases the issue goes
> away when I run libreoffice using the above mentioned env variable.
> 
> Cheers

Out of curiosity I tried german layout (swiss: ch). It behaves the same way as us and pl. That is, when I run libreoffice using SAL_USE_VCLPLUGIN=gtk3 the shortcut works as expected.

I tested the 4 following possibilities, none of them works :
1/ vclplugin=gtk3 (my default)
2/ vclplugin=gtk
3/ vlcplugin=gen
4/ English keybord layout (qwerty)

I can redefine the shortcut to "Ctrl+Shift+," or "Ctrl+shift+H" (or any other letter), but not to "Ctrl+Shift+'"
With the key ";" the only 3-keys shortcut that works is "Ctrl+Alt+;" 
"Shift+Alt+;" does not work too.

Best regards. JBF

*** Bug 125306 has been marked as a duplicate of this bug. ***

(In reply to Martin from comment #6)
> I tested for polish ( pl ) and english ( us ). In both cases the issue goes
> away when I run libreoffice using the above mentioned env variable.

Thanks. I can reproduce now if I switch keyboard layout to US.

What both US and PL keyboard layouts have in common is that the ";" character is typed by just pressing a single key, while DE layout requires typing Shift in addition to the key otherwise typing ",'.
For the US layout, pressing Shift in addition to the ";" key will result in ":".

This is what **might** be happening (didn't check yet): Instead of the three key codes for Ctrl + Shift + ';', only the key codes for Ctrl + ':' are sent,
(i.e. the conversion
    Shift+';' = ':'
takes place), and the shortcut then no longer matches.

(In reply to Michael Weghorn from comment #10)
> (In reply to Martin from comment #6)
> 
> Thanks. I can reproduce now if I switch keyboard layout to US.
> 
> What both US and PL keyboard layouts have in common is that the ";" [...]

Actually, physically PL keyboard looks exactly like the US one. The way you get characters specific to Polish language is by key combination of right Alt key and a letter (eg. RightAlt+a).

I'm guessing that if it gets fixed for US layout, it'll also be fixed for other derived from it.

I quickly debugged into the code and at a quick glance at 'Qt5Widget::handleKeyEvent', it seems like this is passed in the QKeyEvent:

* for DE layout: key: Semicolon; modifiers: Shift + Ctrl
* for US layout: key: Colon; modifiers: Shift + Ctrl

(In reply to Martin from comment #0)
> Actual Results:
> semicolon character is inserted into the cell

@Martin: Does this actually insert a semicolon (";") character or a colon (":")? If it's actually a semicolon, that somewhat contradicts my expectations.

@JBF: What keyboard layout are you using? Does the behaviour change when you switch e.g. to US layout?

(In reply to Michael Weghorn from comment #12)
> I quickly debugged into the code and at a quick glance at
> 'Qt5Widget::handleKeyEvent', it seems like this is passed in the QKeyEvent:
> 
> * for DE layout: key: Semicolon; modifiers: Shift + Ctrl
> * for US layout: key: Colon; modifiers: Shift + Ctrl
> 
> (In reply to Martin from comment #0)
> > Actual Results:
> > semicolon character is inserted into the cell
> 
> @Martin: Does this actually insert a semicolon (";") character or a colon
> (":")? If it's actually a semicolon, that somewhat contradicts my
> expectations.
> 
> @JBF: What keyboard layout are you using? Does the behaviour change when you
> switch e.g. to US layout?

You're right, it's a colon (:). Sorry abut the confusion.

(In reply to Michael Weghorn from comment #12)
> [...]
> @JBF: What keyboard layout are you using? Does the behaviour change when you
> switch e.g. to US layout?

Keyboard layout: Français(Variante)
No change if I use an English/US layout (see comment #8)

Best regards. JBF

Thanks for the clarifications.

I checked with a small sample Qt application that the values for the keys for QWidget::handleKeyEvent are submitted as described in comment 12 (i.e. Colon for US, Semicolon for DE layout).

I wouldn't say that this by itself is wrong, and it seems a bit unfortunate that the choice of allowed/used keyboard shortcuts including the Shift key allows for such ambiguous situations...

Right now, I don't really have a good idea on how to deal with this. It probably makes sense to take a closer look what e.g. gtk3 does (i.e. both the gtk framework and the LO gtk3 VCL plugin).

(In reply to Michael Weghorn from comment #15)
> Thanks for the clarifications.
> 
> I checked with a small sample Qt application that the values for the keys
> for QWidget::handleKeyEvent are submitted as described in comment 12 (i.e.
> Colon for US, Semicolon for DE layout).
> 
> I wouldn't say that this by itself is wrong, and it seems a bit unfortunate
> that the choice of allowed/used keyboard shortcuts including the Shift key
> allows for such ambiguous situations...
> 
> Right now, I don't really have a good idea on how to deal with this. It
> probably makes sense to take a closer look what e.g. gtk3 does (i.e. both
> the gtk framework and the LO gtk3 VCL plugin).

I see.

Has something changed? This shortcut worked fine before I installed the latest version of Libre Office. I've been using this shortcut for close to two years now.

(In reply to Martin from comment #16)
> Has something changed? This shortcut worked fine before I installed the
> latest version of Libre Office. I've been using this shortcut for close to
> two years now.

The "kde5" (or "kf5") VCL plugin ("frontend") which is used on Plasma and LXQt by default, was only introduced with LibreOffice 6.2, so you were probably using "gtk3" or "gtk3_kde5" VCL plugin previously, which still works the same (as comment 3 says).

Another "interesting" case is that Ctrl+Shift+; inserts current time, while Ctrl+; inserts the date.
I see no way to actually insert the date like this when used e.g. with German keyboard layout , since typing ";" requires pressing Shift+, - so the time is inserted instead of the date. And I currently can't up with any "technical" solution to actually make both of them work at the same time, other than changing keyboard shortcuts (depending on layout??).

(In reply to Michael Weghorn from comment #17)
> The "kde5" (or "kf5") VCL plugin ("frontend") which is used on Plasma and
> LXQt by default, was only introduced with LibreOffice 6.2, so you were
> probably using "gtk3" or "gtk3_kde5" VCL plugin previously, which still
> works the same (as comment 3 says).

So this can not be called a regression, removing keywords.

*** Bug 149331 has been marked as a duplicate of this bug. ***

I have this issue (only Insert/Time, not Insert/Date) with 

Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
7.5.4-3
Calc: threaded

On ArchLinux/amd64, with GNOME 44.3 and a Dvorak(intl, with dead keys) layout.

It only started happening recently, and wasn't present in earlier 7.5 minor.

Using `SAL_USE_VCLPLUGIN=gtk3 soffice` doesn't fix the issue.

Note that, unlike the original report, the Ctrl+Shift+; shortcut does nothing. It does not output a ";" in the current cell.

Version: 7.4.7.2 (x64) / LibreOffice Community
Build ID: 723314e595e8007d3cf785c16538505a1c878ca5
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: sv-SE (en_GB); UI: en-GB
Calc: threaded

It has now changed for me also. I no longer get the semicolon ";" - just a blank cell. Still a Scandinavian keyboard.
FWIW If I insert a time using the menu insert time or the ribbon button into a blank cell so it is preformatted as a time value there are two? responses.
If the time is still present no operation so the time remains
If the time valkue is expunged first then still no operation the blank cell remains.

(In reply to Olivier Mehani from comment #20)
> On ArchLinux/amd64, with GNOME 44.3 and a Dvorak(intl, with dead keys)
> layout.

The same happens with a us(intl, with dead keys), and just plain us layout (no dead keys)

(In reply to Michael Weghorn from comment #10)
> This is what **might** be happening (didn't check yet): Instead of the three
> key codes for Ctrl + Shift + ';', only the key codes for Ctrl + ':' are sent,
> (i.e. the conversion
>     Shift+';' = ':'
> takes place), and the shortcut then no longer matches.
seems confirmed by what others report, e.g. comment 11.

(In reply to Cor Nouws from comment #23)
> (In reply to Michael Weghorn from comment #10)
> > This is what **might** be happening (didn't check yet): Instead of the three
> > key codes for Ctrl + Shift + ';', only the key codes for Ctrl + ':' are sent,
> > (i.e. the conversion
> >     Shift+';' = ':'
> > takes place), and the shortcut then no longer matches.
> seems confirmed by what others report, e.g. comment 11.

On a Scandinavian keyboard the semicolon is shift comma and the colon is shift fullstop(point) so the shift modifier should be the desired semicolon. The solution probably needs to rationalise the potential "double" shift implication

I suffered this issue, and suspected a global input interceptor. It turned out to be an issue in LibreOffice Calc; the "shift ctrl :" shortcut needs to be assigned to "Insert Current Time" **not** "shift ctrl ;".  
  
See more details at: https://forums.linuxmint.com/viewtopic.php?p=2509498#p2509498

(In reply to studog from comment #25)
> I suffered this issue, and suspected a global input interceptor. It turned
> out to be an issue in LibreOffice Calc; the "shift ctrl :" shortcut needs to
> be assigned to "Insert Current Time" **not** "shift ctrl ;".  
>   
> See more details at:
> https://forums.linuxmint.com/viewtopic.php?p=2509498#p2509498

Unfortunately, not all keyboards are the same. Most European and Latin Asian keyboards have the colon and semi-colon keys as adjacent keys on the bottom row [Shift] stop and [shift] comma, whereas US keyboards use the [Shift] modifier on a single middle row key which is predominantly a key for other languages' special vowels.

The modification you desire may well cause grief for a substantial portion of the 200 million other users who already leverage the unique mapping of those vowels for other user keyboard shortcuts.

(In reply to Colin from comment #26)
> Unfortunately, not all keyboards are the same. Most European and Latin Asian
> keyboards have the colon and semi-colon keys as adjacent keys on the bottom
> row [Shift] stop and [shift] comma, whereas US keyboards use the [Shift]
> modifier on a single middle row key which is predominantly a key for other
> languages' special vowels.
> 
> The modification you desire may well cause grief for a substantial portion
> of the 200 million other users who already leverage the unique mapping of
> those vowels for other user keyboard shortcuts.

My keyboard layout, language and locale are all correct and set for US English. In this setup either "shift ctrl ;" should function as expected to "Insert Current Time", or, "shift ctrl :" should also be set to "Insert Current Time".  
  
Said another way...

In US English keyboard layout "shift ctrl ;" is an impossible keychord, except, by convention, keychords that use shift often refer to the non-shifted character on the key. If LibreOffice wants to abandon the convention, that's fine, but breaking normal usage to do so is wrong.

All the reports about keyboard shortcuts aimed at inserting date and/or time will keep showing up in one way or another, until the shortcuts (for any UI language, any OS language, and any keyboard layout) are implemented as:

* "Insert current date"
[CTRL]+ "whichever method to type a semicolon character, no matter its location on the keyboard layout."


* "Insert current time"
[CTRL]+ "whichever method to type a colon character, no matter its location on the keyboard layout."

If the specific keys (semicolon and colon) are introduced by adding [SHIFT], or [AltGr], or no other auxiliary keys, or any other auxiliary key, it should not matter.

As for the way it is expressed, we (users) do not care, as long as it is clearly understood, and that it works consistently.

It's been years, with multiple reports, depending on keyboard layout, OS language, OS type, OS version, input language, LO UI language, LO version...