VK_PACKET inputs for range U+3000 to U+30FF produces "stale" characters

[iBug]

Steps to reproduce

1. Compile the following C program:

   #include <stdlib.h>
   #include <windows.h>
   
   int main() {
       INPUT *inputs = malloc(sizeof(*inputs) * 100);
       int count = 0;
   
       const WORD codes[] = {0x300A, 0x300B, 0x3008, 0x3009, 0x300E, 0x300F};
       const int codes_count = sizeof(codes) / sizeof(codes[0]);
   
       // Create a pair of keydown+keyup events for each character
       for (int n = 0; n < codes_count; n++) {
           INPUT i = {
               .type = INPUT_KEYBOARD,
               .ki = {
                   .wScan = codes[n],
                   .dwFlags = KEYEVENTF_UNICODE,
               },
           };
           inputs[count++] = i;
           i.ki.dwFlags |= KEYEVENTF_KEYUP;
           inputs[count++] = i;
       }
   
       Sleep(3000);
       SendInput(count, inputs, sizeof(*inputs));
       free(inputs);
   }

2. Start the program, then in 3 seconds: switch to TDesktop, and put the focus on a text box (either search box or a chat - both will work).

3. Watch the characters being typed into the box.

Expected behaviour

Characters 《》〈〉『』 appear in the input box.

Actual behaviour

Characters 《《《《《《 appear in the input box.

Notes

Originally reported as samhocevar/wincompose#512, but I later realized this has to do with TDesktop (or even Qt). TDesktop is the only Qt program I have on my Windows computer, so I could not verify the behavior of Qt in general, and I figured out I'd report to TDesktop first.

A precise description of this bug would be:

• When TDesktop receives a contiguous run of VK_PACKET inputs where all Unicode characters fall in the range U+3000 to U+30FF, each character of the entire sequence turns into the first character. Additionally, the next out-of-Unicode-range VK_PACKET input also turns into the first character of the sequence.

To demonstrate this, change codes in the C code to the following:

const WORD codes[] = {0x300A, 0x300B, 0x3008, 0x2605, 0x3009, 0x300E, 0x300F};
//                                            ^ insert

Then the expected result would be 《》〈★〉『』, but the actual result is 《《《《〉〉〉. Notice how U+2605 ★ also became U+300A 《, while still enabling the next contiguous run of U+3009 〉.

Operating system

Windows 10, Version 22H2 (OS Build 19045.3324)

Version of Telegram Desktop

4.8.10 - older versions (at least down to 4.6.2) are also affected

Installation source

Static binary from official website

Crash ID

No response

Logs

No response

[ilya-fedin]

I'm highly doubt anyone here would help you with that. It would be faster if you check other Qt applications and debug this yourself.

[iBug]

@ilya-fedin Sorry but I do neither Windows or Qt development. If someone else can help confirm this bug maybe we can report to upstream Qt.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[iBug]

not stale