Corrupted clipboard data (was: InputTextMultiline gibberish)

[LPVOIDDev]

Version/Branch of Dear ImGui:

Version: Dear ImGui 1.83 WIP (18203)
Branch: master

Back-end/Renderer/Compiler/OS

Original Back-ends from ImGUI Repository
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_opengl3

Compiler: Visual Studio 2015 (v140)
Operating System: Windows 10

My Issue/Question:

When copying text, sometimes it gives the wrong results
It is very easy to reproduce in the demo version

1. Go to Demo > Widgets > Text Input > Multi-line Text Input
2. Delete all text and type 33 ones and press enter ("111111111111111111111111111111111\n")
3. Ctrl+A, Ctrl+C, Ctrl+V

The result will be some gibberish text.

Screenshots/Video

Standalone, minimal, complete and verifiable example:

static char text[1024 * 16] = "111111111111111111111111111111111\n";
static ImGuiInputTextFlags flags = ImGuiInputTextFlags_AllowTabInput;
ImGui::CheckboxFlags("ImGuiInputTextFlags_ReadOnly", &flags, ImGuiInputTextFlags_ReadOnly);
ImGui::CheckboxFlags("ImGuiInputTextFlags_AllowTabInput", &flags, ImGuiInputTextFlags_AllowTabInput);
ImGui::CheckboxFlags("ImGuiInputTextFlags_CtrlEnterForNewLine", &flags, ImGuiInputTextFlags_CtrlEnterForNewLine);
ImGui::InputTextMultiline("##source", text, IM_ARRAYSIZE(text), ImVec2(-FLT_MIN, ImGui::GetTextLineHeight() * 16), flags);

[PathogenDavid]

I can't reproduce this issue on my machine.

If you paste the text in something else like Notepad or Visual Studio does it appear corrupted there as well?

Edit: Also does it still happen if you comment out the following lines in imgui_impl_glfw.cpp?

imgui/backends/imgui_impl_glfw.cpp

Lines 176 to 178 in d6a5cc7

	io.SetClipboardTextFn = ImGui_ImplGlfw_SetClipboardText;
	io.GetClipboardTextFn = ImGui_ImplGlfw_GetClipboardText;
	io.ClipboardUserData = g_Window;

(This will cause the clipboard to be handled by Dear ImGui's implementation instead of the GLFW's. Their implementations are basically the same, but aren't quite identical.)

[LPVOIDDev]

@PathogenDavid thank you very much for interest and the tips

1. I've tried to copy 1's and paste to plain notepad, the result is the same 33yPjjSMGHPp8zj1ZXySNJzSUfVSbpXEuL
2. I've tired to comment out those three lines you mentioned in the imgui_impl_glfw.cpp, the result was the same

I've updated the GIF in the topic to more elaborate reproduction. In that gif I've used the original example source without changing anything (git cloned everything to a new location to make sure everything's intact).
Standalone, minimal, complete and verifiable example is only there for sake of completeness of the issue template. The issue is actually reproducible on the original examples.

[PathogenDavid]

@LPVOIDDev No problem!

In that gif I've used the original example source without changing anything (git cloned everything to a new location to make sure everything's intact).

Thanks for clarifying! I tried the manual typing as in your gif as well as your code snippet.

I did some investigation and I have two theories as to what might be wrong, but since I can't reproduce this issue on my machine I can't validate those theories.

Could you clone this GH-4029 branch from my fork and run the example_glfw_opengl3 project again?

This fork adds this small test window:

Click Run test 00 and try pasting in Notepad and note the results. Repeat again for each of the other 3 tests.

If you could copy+paste the output logged in the console window that'd be very helpful as well.

[LPVOIDDev]

@PathogenDavid thank you very much

Looks like your theory is correct!

The results for four tests are the following:

1. 33yPjjSMGHPp8zj1ZXySNJzSUfVSbpXEuL
2. 33yPjjSMGHPp8zj1ZXySNJzSUfVSbpXEuL
3. 111111111111111111111111111111111
4. 111111111111111111111111111111111

Log from cmd:

==================================================
Clipboard test 0, 0
==================================================
Opening the clipboard...
Emptying the clipboard...
Allocating the clipboard buffer...
Populating the clipboard buffer...
Setting the clipboard data...
Done!
==================================================
Clipboard test 0, 1
==================================================
Opening the clipboard...
Emptying the clipboard...
Allocating the clipboard buffer...
Populating the clipboard buffer...
Setting the clipboard data...
Adding locale ID...
Successfully populated the locale ID.
Done!
==================================================
Clipboard test 1, 0
==================================================
Opening the clipboard...
Emptying the clipboard...
Allocating the clipboard buffer...
Populating the clipboard buffer...
Setting the clipboard data...
Done!
==================================================
Clipboard test 1, 1
==================================================
Opening the clipboard...
Emptying the clipboard...
Allocating the clipboard buffer...
Populating the clipboard buffer...
Setting the clipboard data...
Adding locale ID...
Successfully populated the locale ID.
Done!

[PathogenDavid]

Excellent, thanks for testing that! I'll get a proper fix for both Dear ImGui and GWFL written and submitted sometime this weekend.

If you're curious, the "cause" is this definition for the CF_UNICODETEXT clipboard format that both Dear ImGui and GWFL use:

Unicode text format. Each line ends with a carriage return/linefeed (CR-LF) combination. A null character signals the end of the data.

It's really weird that it's causing an issue to use \n instead of \r\n on your system but not mine.

For my own curiosity: What language is your system in? Do you have any apps installed that might mess with the clipboard? (Maybe look through the startup tab in Task Manager.) Do you have clipboard sync enabled in Settings > System > Clipboard?

[LPVOIDDev]

@PathogenDavid Thank you very much!

• The system language is Russian
• The system locale is Russia
• Clipboard sync in the settings is disabled
• No other apps that mess with clipboard

Actually there was a bigger issue that led me to reveal this bug.
When I set the input text buffer length to 1024, and then try to paste a very long string a few times, the whole thing would hang forever like there is an infinite loop. But this is easily fixed by doubling the buffer size. I am very curious though as to why this could happen... By some trials I've found out that this happens on buffer sizes up to 1390, and stops happening above that. So currently I'm using the buffer size of 1391 bytes. In the process of these trials I've found this 1111...'s thing.

[PathogenDavid]

Thanks for the info! I've submitted a PR for Dear ImGui's implementation here: #4036

---

• The system language is Russian
• The system locale is Russia

I was hoping changing my system language to Russian would let me reproduce it locally, but sadly it does not:

---

When I set the input text buffer length to 1024, and then try to paste a very long string a few times, the whole thing would hang forever like there is an infinite loop. But this is easily fixed by doubling the buffer size. I am very curious though as to why this could happen...

I'm very curious as well! Unfortunately I'm not experiencing this issue either, but I didn't dig very far. You should try pausing the app in your debugger to see where it's getting stuck.

[LPVOIDDev]

Thanks for the info! I've submitted a PR for Dear ImGui's implementation here: #4036

@PathogenDavid thank you very much!
I can confirm this fixes the issue and the bug is gone on this branch.

I'm very curious as well!

I've found out about the issue and the way to reproduce it reliably (at least on my machine)
I've opened the new issue here #4038 (comment) you can check it out if you're curious :)

[ocornut]

Thank you both @LPVOIDDev for reporting and @PathogenDavid for the incredible investigation :)
Will reply in #4036

[r00tw33d]

Hi there,

Most probably @LPVOIDDev is infected with cliptomaner (see the Kaspersky report), a malware that searches the clipboard for strings that match a Bitcoin address pattern, and replaces them with a different address. 33yPjjSMGHPp8zj1ZXySNJzSUfVSbpXEuL is not gibberish but the replace (Bitcoin) address of the attacker.

It's very straightforward: 111111111111111111111111111111111 matches the pattern of a Bitcoin address, that's why it is replaced within the clipboard of the O.S. (not an issue related with Dear ImGui). The same should happen with other Bitcoin addresses, give it a try.

Hope it makes sense.

[LPVOIDDev]

@r00tw33d Thank you very much!

This seems to be true! But this didn't partly. The example with 33 1's didn't work on notepad, but it really did convert real bitcoin addresses to that exact value.
I took some real bitoin address examples from bitcoin wiki and did a quick test, here's the results

[PathogenDavid]

Oh wow thanks for sharing, @r00tw33d!

I didn't even think to look up the garbage. I just assumed it was uninitialized memory that happened to be the same every time for whatever reason. (I actually considered asking @LPVOIDDev to reboot to see if it changed but never bothered.)

So really I just found a bug in the dumb virus 🙃

[LPVOIDDev]

@PathogenDavid yeah and it's insane how imgui community helped me find a virus on my machine that's been sitting there silently since September 2020! (according to task creation date)

[ocornut]

Closing, but I imagine we'll make sure to ample link at this issue in the future :) Should get a honorable mention in the next release note!