Paste from clipboard doesn't always work

[mdrustad]

Windows Terminal version

1.15.2874.0

Windows build number

10.0.19044.2130

Other Software

Old Intel workbench internal tool Notepad++ v8.4.1

Steps to reproduce

Copy some text out of the old workbench tool and attempt to paste it into Terminal. Nothing is pasted. I can paste into Notepad++. If I do, I can then copy that text from Notepad++ and then paste it into terminal. Without knowing any details, it seems to me that Notepad++ is supporting some older clipboard methodology that is not present in Terminal. Please add whatever it is that is missing in Terminal.

Expected Behavior

What was copied should have been pasted into Terminal as input.

Actual Behavior

Nothing is pasted when data is copied from that old app.

[zadjii-msft]

What application is running in the Terminal that you're pasting into? How are you pasting (ctrl+shift+v, right mouse button, from the command palette...)/?

Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can?

[mdrustad]

On Nov 2, 2022, at 2:46 PM, Mike Griese @.***> wrote:

What application is running in the Terminal that you're pasting into?

It is an old IDE used for microcode development, maybe based on a very old visual studio? Anyway, very old.

How are you pasting (ctrl+shift+v, right mouse button, from the command palette...)/?

ctrl+shift+v, which does work after I copy from Notepad++. Which is able to accept the paste from the old app. That is what led me to report this on Terminal rather than grouse about the old program (there are always old programs).

Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can?

It really can't be anything other than plain text. I know nothing about Windows development, so I can really only observe the difference in behavior between Terminal and Notepad++ for example.

-- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

[mdrustad]

On Nov 2, 2022, at 2:46 PM, Mike Griese @.***> wrote:

Without knowing more about the application in question, I'm not sure how we'd be able to figure out what "older clipboard methodology" they're using which we're apparently not supporting. Maybe they're setting a specific type of clipboard format (RTF? HTML?) that we're not looking for, but notepad++ can?

I had a thought on this. I'm sure that the old app predates UTF-8, which I expect any modern program to be using for text. The program is at least 20 years old, so UTF-8 really wasn't a thing back then. Presumably it would indicate some older encoding. ASCII or whatever PC standard was called (I used to at least know that).

A wild guess. Like I said, I know nothing about Windows apps, but it is a thought.

-- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

[carlos-zamora]

Our leading suspicion is #14129 but we can't be 100% sure. Since we're hoping to release a patch for this, we'll circle back and see if that fixes it.

[mdrustad]

On Nov 7, 2022, at 1:17 PM, Carlos Zamora @.***> wrote:

Our leading suspicion is #14129 but we can't be 100% sure. Since we're hoping to release a patch for this, we'll circle back and see if that fixes it.

I was going to say that it didn't seem t be related until I got to the part about uninitialized memory! Anyway, I tried the showkeys -a thing that was mentioned and it returned nothing when I pasted a clipbaord form that old app. Also, FWIW, it also won't paste into a Windows shell in Terminal, but I can into cmd.exe.

So unlikely related to bracketed paste, but possibly somehow related to uninitialized memory (since that could be most anything). Or not.

-- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

[zadjii-msft]

Anyway, I tried the showkeys -a thing that was mentioned and it returned nothing when I pasted a clipbaord form that old app. Also, FWIW, it also won't paste into a Windows shell in Terminal, but I can into cmd.exe.

Well, shiz. That rules out the uninitialized memory one. Basically, whatever data is getting onto the clipboard, Terminal can't get out with

https://github.com/microsoft/terminal/blob/a798a603e1256b2823483b0459077df97ff0eb3a/src/cascadia/TerminalApp/TerminalPage.cpp#L2173-L2176

Clipboard.GetContent docs

I'm kinda lost at this point. Without the application that repros this, I don't know how we could possibly investigate more. Maybe a Feedback Hub trace, with the area being the "clipboard" might get more info, but I wouldn't know what part of that to dig through.

[zadjii-msft]

We would basically need to know what the format of the clipboard content was, to be able to look for it. more docs.

Also curious: https://github.com/microsoft/terminal/blob/a798a603e1256b2823483b0459077df97ff0eb3a/src/interactivity/win32/Clipboard.cpp#L67-L72

the vintage console (what you're thinking of when you think cmd.exe) is only ever looking for CF_UNICODETEXT, which I'm under the impression is the same as StandardDataFormats::Text()

[mdrustad]

On Nov 8, 2022, at 7:56 AM, Mike Griese @.***> wrote:

the vintage console (what you're thinking of when you think cmd.exe) is only ever looking for CF_UNICODETEXT, which I'm under the impression is the same as StandardDataFormats::Text()

Maybe somewhere along the line the ability to convert 8-bit chars, ala ASCII, UTF-8, etc., into WCHAR was missed? It seems likely to be in the libraries somewhere. I don't know what is different between cmd and Terminal, but there should be a clue there as to what ingredient has the issue. It seems to me like Terminal would be using the newest stuff and newer is not always better.

Hmm. One other thing I should mention is that I am accessing this system via Remote Desktop from a Mac. Though in this case the copying and pasting is between two apps on the target, maybe the remote access has an effect on the clipboard somehow?

-- Mark Rustad (he/him), Ethernet Products Group, Intel Corporation

[zadjii-msft]

accessing this system via Remote Desktop from a Mac

That certainly might have something to do with it! Some rudimentary googling suggests restarting rdpclip.exe. No idea if that would actually help, but the modern app platform has definitely taken dependencies on unexpected parts of the OS in the past.

[mdrustad]

Maybe, but I kind of doubt it. I can copy/paste between everything else successfully. It is just copying from that old workbench app into Terminal in the same system that doesn't work. Recall I can paste into Notepad++ in the same environment. It is only Terminal that has the problem. The regular command prompt also receives the paste just fine. All accessed via RDP on the same system.

[mdrustad]

FWIW, I just tested this on a system without RDP involved and got the same result. I am unable to paste into Terminal that which was copied from a text window in that old IDE. The paste works fine in the traditional command prompt, Notepad++ and even Word. Only the new Terminal seems to have the problem.

[zadjii-msft]

Does pasting into any other UWP-like apps work? Something like... the builtin Mail or Calendar apps (I think they're UWPs). Sticky Notes might be a built-in UWP too. Any of those should be using the modern clipboard APIs.

I know it's an internal tool, but with the name of it, I might be able to search our internal bug database for issues, if any had been opened before.

Another theory - perhaps this internal tool is using EDP to try and protect the clipboard contents, and Terminal is either obeying / not obeying those APIs. I know that's something we added support to the console in the past, but I don't think we ever did anything for the Terminal.

[zadjii-msft]

Found on an internal thread

Clipboard does not support UTF-8. Apps are doing a workaround of using CF_UNICODETEXT and doing manual conversion from UTF-8 to UTF-16.

Interesting. I wonder if the tool you're using is setting the content as UTF-8,

... but honestly that doesn't sound right at all...

[zadjii-msft]

From my contact on the Clipboard team:

We would need clipboard logs from feedback hub repro under the "Copy and Paste" node to diagnose. 

They could try using free clipboard viewer to see what formats are placed on the clipboard: Free Clipboard Viewer for Windows - Download 

CAVEAT: This isn't an application from Microsoft. I honestly don't know how legit it is. But they did mention it has been used to view clipboard content since they have worked in the area

But if you file /feedback under "Copy and Paste", and share the aka.ms link here, I can make sure it gets in the right folks hands.

[ghost]

Hi there!

Can you please send us feedback with the Feedback Hub with this issue? Make sure to click the "Start recording" button, then reproduce the issue before submitting the feedback. Once it's submitted, paste the link here so we can more easily find your crash information on the back end?

Thanks!

[mdrustad]

Does pasting into any other UWP-like apps work? Something like... the builtin Mail or Calendar apps (I think they're UWPs). Sticky Notes might be a built-in UWP too. Any of those should be using the modern clipboard APIs.

I can confirm that it also doesn't work in Sticky Notes.

I know it's an internal tool, but with the name of it, I might be able to search our internal bug database for issues, if any had been opened before.

The name of it is "Developer Workbench".

Another theory - perhaps this internal tool is using EDP to try and protect the clipboard contents, and Terminal is either obeying / not obeying those APIs. I know that's something we added support to the console in the past, but I don't think we ever did anything for the Terminal.

I have no idea and no way to know.

I did run the Feedback Hub. The link is: https://aka.ms/AAj021g

[4nqyi]

Subscribed since I’ve been having the same issue. If a block of text is already selected in the terminal this will remain in the clipboard (clip1) buffer even after selecting text from another application but only in the terminal clipboard (terminal1), so after you’ve copied (clip2) from another application and try to paste it to terminal1 you end up pasting the text from clip1.

Is there an option to clear the clipboard buffer if text is copied from another application? Putty clears the clipboard before copying form another application.

Windows Terminal Version: 1.15.3465.0

"copyOnSelect": true,

clipboard test https://youtu.be/r2bklE0naT4

[mdrustad]

Hmm. Your issue is different, though I have observed that behavior, as well. In my case there is no selection in Terminal to override the clipboard contents for the pastes that aren't working for me. I hadn't yet thought to complain about your issue because this other issue causes me much more grief.

[zadjii-msft]

@4nqyi You're probably seeing the same thing as #14464 tbh

[zadjii-msft]

Pre-emptively, did you make sure to capture the recording with the Feedback Hub when submitting feedback? I don't think I'd be able to do anything with the logs if they're there, BUT I'm also not seeing the normal kinds of logs attached. Again, maybe clipboard tracing is attached differently, but I'm guessing it didn't get attached 😞

[mdrustad]

Like I said, I ran the Feedback Hub and it gave me this link: https://aka.ms/AAj021g

[ophers]

I was going to open a new bug report but found this one. I have the exact same behavior, except in my case it's not an "Old app" rather a WSLg window.

Reproducing:

I'm running Windows 11 with Microsoft store latest WSL - that includes WSLg.

1. I open Eclipse CDT (latest) from within a WSL terminal window (running CentOS 7).
2. I copy text from Eclipse.
3. Trying to paste to the WSL terminal window fails - nothing pasted.
4. Also nothing pasted to ANY Windows Terminal tab I open (CMD, Powershell, etc.), neither to a new Terminal window I open.

But, it will paste to:

1. The find box of Windows Terminal
2. To a conhost.exe windows started from windows "Run" bar.
3. To Notepad

[RobMahn]

I was having a similar issue with WSL and discovered that pasting text with a leading tab character, or even manually entering a tab key at the command prompt will crash the terminal. Ctl-C does not clear or recover. ^C is displayed, but no other keys are accepted. You must close this window and open another.

[DHowett]

I was having a similar issue with WSL and discovered that pasting text with a leading tab character, or even manually entering a tab key at the command prompt will crash the terminal. Ctl-C does not clear or recover. ^C is displayed, but no other keys are accepted. You must close this window and open another.

Turns out that's because tab completion in WSL is occasionally very slow. The tab character is just triggering tab completion. That's not a great experience though.

Your shell should be activating "bracketed paste mode" so that it doesn't attempt tab completion while you're pasting.

[avih]

Was the source of the issue identified?

I'm observing the same[*] issue where paste doesn't work when text is copied using win32 SetClipboardData(CF_UNICODETEXT, ...). Tested in Terminal versions 1.15 up to latest git master.

[*] Not exacty the same, because it seems sometimes it does paste after copy with SetClipboarData, but mostly it doesn't paste, and I don't know how to reproduce success/fail reliably.

For reference, here is a C program where pasting at the Windows terminal usually doesn't work after copying using e.g. clipw32 foobar - but it does paste elsewhere just fine, like in notepad, or in OpenConsole.exe which ships with the windows terminal. Compiled using mingw gcc in w64devkit.

clipw32.c

// compile using mingw: gcc -municode clipw32.c -o clipw32.exe

#include <stdio.h>
#include <windows.h>

int wmain(int argc, wchar_t **wargv)
{
    if (argc != 2) {
        fprintf(stderr, "Usage: clipw32 TEXT    Copy TEXT to clipboard\n");
        return 1;
    }

    int nbytes = sizeof(wchar_t) * (1 + wcslen(wargv[1]));
    void *data;
    HGLOBAL h;

    if (   (h = GlobalAlloc(GMEM_MOVEABLE, nbytes))
        && (data = GlobalLock(h))
        && memcpy(data, wargv[1], nbytes)
        && GlobalUnlock(h) == 0
        && OpenClipboard(NULL)
        && SetClipboardData(CF_UNICODETEXT, h))
    {
        CloseClipboard();
        return 0;
    }

    fprintf(stderr, "clipw32: copy failed: %u\n", GetLastError());
    return 1;
}

In contrast, this is a similar program in dotnet which copies using Clipboard.SetText(s), where paste at the terminal seem to always succeed after copying using e.g. clipnet hello:

clipnet.cs

class Program {
    [System.STAThreadAttribute]
    static int Main(string[] args) {
        if (args.Length == 1) {
            System.Windows.Forms.Clipboard.SetText(args[0]);
            return 0;
        }
        System.Console.Error.Write
            ("Usage: clipnet TEXT    Copy TEXT to clipboard\n");
        return 1;
    }
}

[avih]

I don't know how to reproduce success/fail reliably.

Actually, here are some data points:

Paste after copy using SetClipboardData seems likely to succeed right after launching the terminal, even several different copy/pastes in a row.

One time, in a long-running instance of the terminal (few days), after copying foo using SetClipboardData, pasting in other programs pasted foo correctly, while at the windows terminal it pasted something else which was copied earlier. This is terminal git master from about a week ago (CI artifact).

This happened repeatedly (paste in notepad: foo, in the terminal: old text, in notepad: foo, at the terminal: old text).

This is a wild guess, but one possible "scenario" could be that the terminal "watches" for clipboard changes, but it doesn't identify the change in some cases if the update was using SetClipboardData.

EDIT: OK, I think I've identified the cause:

If I add to the C program before OpenClipboard(NULL):

&& OpenClipboard(NULL) && EmptyClipboard()  // owner becomes NULL

Then it seems to paste successfully also at the windows terminal.

However SetClipboardData(...) succeeds even without EmptyClipboard(), it does paste correctly elsewhere, and as far as I can tell the docs don't mention that emptying the clipboard is mandatory before copy - https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setclipboarddata

So it would seem like something at the windows terminal looks for clipboard clear event before it updates its internal copy of the clipboard data, and if the clipboard updates without a clear, then the terminal's clipboard data could become stale or otherwise incorrect.

[lhecker]

The current WinRT API we use is a wrapper around the OLE clipboard API which is a wrapper around the Win32 clipboard API and somewhere along the way (= many 10k of LOC) there's probably a bug. But if what you write is true then that's almost certainly going to be fixed by #15360 as it uses the counterpart to the API above to read the clipboard contents (including the use of CF_UNICODETEXT).

[avih]

if what you write is true then that's almost certainly going to be fixed by #15360

Probably. I thought the info might be useful in finding the source of the issue, but you know better than me which solution is best for you.

[DrChr]

Hi, not sure this is the right issue, but I'd like to report that this issue might not have been fixed.

I'm on version Version: 1.18.3181.0 of Windows Terminal and have intermittent issues where paste doesn't work.

I think the version I have is after #15360 was merged, but I'm not sure. However, if my version is after the merge, this issue might not have been fixed.

In my case I've attempted to copy from a MS Word document. The failed pastes are intermittent though. When I just tried to reproduce, it worked. (And then I'd first selected some text in this edit form and then successfully pasted that, after which I could copy from MS Word and then paste).

[lhecker]

Intermittent paste issues also happen to me, but I don't think they're related to Windows Terminal. I routinely (once or twice a month) can't copy anything from my browser to Outlook for instance, but when I try to copy from a different application it randomly resolves itself. It might be a bug in the Office code base for instance, or maybe even Windows itself (with all that WinRT clipboard server stuff). It is possible that this is also a bug in Windows Terminal and it just happens to be a bug that independently exists in multiple applications, but I suspect that this would be somewhat less likely.