Windows clipboard issues discussion

[mbien]

Copying text in and out of NetBeans stops working for some users on windows, this thread discusses #3962 on the adventurous quest to fix the bug.

[stodge]

For me, CTRL+X in Netbeans temporarily restores the broken copy functionality, until it happens again that is.

[wumpz]

Using Netbeans 23 relaxes most of the problems for me. Most of the time a copy / paste does not work, the second try succeeds. So right direction.

[Chris2011]

I can confirm the problem on Windows and funny thing is, sometimes it works back again. Maybe a raise condition with smth?

[stodge]

Netbeans 23 doesn't seem to improve things for me. It still happens a lot. Occasionally if I try CTRL+C twice it may fix it, but not always.

[jShiwaniGupta]

I can confirm that I’m experiencing this issue as well; it seems to be quite common on Windows. The CTRL+C shortcut often fails to work, which is really frustrating. As a workaround, I’ve been using CTRL+X followed by CTRL+Z to copy text from NetBeans to other applications, but it’s not a reliable solution. Additionally, I’ve noticed that sometimes copying from external apps to the NetBeans editor using CTRL+V also fails, forcing me to open the file in an external editor. I really hope a fix can be implemented soon!

[jGauravGupta]

I completely agree with the frustration expressed in this thread. This clipboard issue is not just frustrating but quite basic and critical for daily workflow. It's concerning that such an essential feature is unreliable, as it may force many developers to switch to other IDEs just to avoid the constant interruptions. A fix for this issue is quite important and would make a huge difference for all of us who rely on NetBeans for efficient development.

[jShiwaniGupta]

I will take a look at NbClipboard.java, as I can only reproduce the issue after working with NetBeans for extended periods.

[eirikbakke]

@jGauravGupta @jShiwaniGupta If either of you have a chance to try it, I'd be curious to hear if the patch posted at #3962 (comment) by any chance fixes the problem.

[jShiwaniGupta]

I downloaded the NetBeans 24 RC1 tag and built it locally for testing. Unfortunately, I was still able to reproduce the clipboard issue. After that, I applied the patch to the NbClipboard and tested it again, but I could still reproduce the problem. It seems that the patch didn't resolve the clipboard issue for my setup.

For testing, I opened the IDE and loaded a Java file, then left it idle for 30-60 minutes. After that, I attempted to copy content from my browser to the IDE, but unfortunately, I was unable to do so.

Edit: I will observe this patch over the next few days to assess if it reduces the overall occurrence of the clipboard issue.

[eirikbakke]

@jShiwaniGupta Thanks a lot for testing! Your report is useful, as it eliminates one (somewhat unlikely) theory I had about the cause of the bug.

[ebresie]

Any logs or profiler dumps available when this happens?

[stodge]

I don’t know if this will help but I typically copy/paste between NetBeans, IntelliJ, Notepad++ and VisualCode. This is on windows 11. I tend to switch apps pretty quickly when I’m copy/pasting but I don’t know if that’s relevant. I also have two external monitors attached to my laptop.

I can’t help with the code but I’ll see if I can build and run from source. Maybe I can quickly try a patched version. I’ve never built NetBeans but if it might help, I can try. I’ll have to check the policy at work on running a patched version though.

[stodge]

I think I can always copy from the Debug output window, and paste it into an external application. So is the problem only related to the main file editor? Or was this fact already known and, as always, I missed it? 😆

[wumpz]

I added a PR to introduce this new retry logic for SetContents as well: #8024.

With this, SetContents and GetContents are equally atomic and do not create new tasks within the executor. With atomic I mean, once it starts processing, it does not create any other tasks but stays within its own thread and holding further processing, till MAX_TRIES is reached or success. The executor has only one thread as a processor.

It is possible that this interference is one reason to break copy and paste in windows, since get and set clipboard could interfere each other. Using this windows hack there always was a GetContens after Netbeans got focus back. I remember using FINE logging for this NbClipboard stuff, I had log messages telling me, that the system clipboard was not reachable. So a collision should be definitely there.

Since there seems to be a timing or threading problem, my guess is that the convert method with all its flavours stuff in it has some complex stuff to do and therefore could take its time. Using this fine logger does a convert again to log out clipboard values. @stodge I cannot confirm, that copy from output window is not affected, but my guess is, that the more complex the editor is I am in, I am copying from, the more likely it becomes a problem.

So having these thoughts, making SetContent and GetContens atomic seems to be the right way to go.

[stodge]

Did #8024 make it into Netbeans 24?

[wumpz]

@stodge Not yet. I am running on it for some time now, but the problem occurs still from time to time. However, I have the "feeling" it is much less than without #8024 and the getContents modifcation. But saying this I am aware that there are very different experiences of this problem from different users.

[stodge]

Thanks, just wanted to confirm.

[niabot]

Netbeans 24: After pasting breaks, copying is also affected. Instead of copying an empty selection (just the cursor), it copies as if the entire line was selected, even if it is (at least visibly) not. Some strange indexing is going on.

[matthiasblaesing]

Netbeans 24: After pasting breaks, copying is also affected. Instead of copying an empty selection (just the cursor), it copies as if the entire line was selected, even if it is (at least visibly) not. Some strange indexing is going on.

That is not a bug, it is a feature. Copy without selection copies current line.

[wumpz]

Any actions here?

[xxDark]

After seeing this on Java's Reddit, I decided to take a look at this (even though I've never used this IDE). I was able to reproduce this issue 100% of the time right from the opening. I've found the root cause and will post a fix once I figure out why this is the case.
In short, AWT is supposed to call lostSelectionOwnershipImpl from the toolkit event loop, but this never happens, leaving cached "contents" in SunClipboard poisoned.
See https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp#L1038 where this should be happening, but it simply doesn't. Either netbeans uses some AWT functions off the event loop thread, making IsGettingOwnership always return true, or something else (overriding WindowProc, etc.)

If one puts a breakpoint here https://github.com/openjdk/jdk/blob/a891630817844c8c42994da3b3110925ca4595a0/src/java.desktop/share/classes/sun/awt/datatransfer/SunClipboard.java#L135 and forcefully sets contents to null, magically, everything will work again.

I added a bit of checking, and indeed, that is what is happening.

Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[System clipboard synchronizer,1,system]
Opening clipboard on thread Thread[AWT-EventQueue-0,6,IDE Main]
Opening clipboard on thread Thread[AWT-EventQueue-0,6,IDE Main]
Update clipboard
Opening clipboard on thread Thread[AWT-Windows,6,system]
FATAL ERROR in native method: oooopsie
        at sun.awt.windows.WClipboard.openClipboard0(java.desktop@17.0.15-internal/Native Method)
        at sun.awt.windows.WClipboard.openClipboard(java.desktop@17.0.15-internal/WClipboard.java:113)
        at sun.awt.windows.WClipboard.handleContentsChanged(java.desktop@17.0.15-internal/WClipboard.java:166)
        at sun.awt.windows.WToolkit.eventLoop(java.desktop@17.0.15-internal/Native Method)
        at sun.awt.windows.WToolkit.run(java.desktop@17.0.15-internal/WToolkit.java:365)
        at java.lang.Thread.run(java.base@17.0.15-internal/Thread.java:840)

Added check in Java_sun_awt_windows_WClipboard_openClipboard:

	if (AwtClipboard::IsGettingOwnership()) {
		env->FatalError("oooopsie");
	}

Edit: I've narrowed down the cause, and this seems to be a bug in the JDK. I'm getting assert failures building AWT with -DDEBUG.
handleContentsChanged seem to be the culprit.

    private void handleContentsChanged() {
        if (AppContext.getAppContext() == null) {
            handleContentsChanged0();
            return;
        }
        EventQueue.invokeLater(this::handleContentsChanged0);
    }
    
    private void handleContentsChanged0() {
        long[] formats = null;
        try {
            openClipboard(null);
            formats = getClipboardFormats();
        } catch (IllegalStateException exc) {
            // do nothing to handle the exception, call checkChange(null)
        } finally {
            closeClipboard();
        }
        checkChange(formats);
    }

Local fix on my machine, I haven't been able to reproduce the issue with this change. Running AWT tests

[mbien]

it isn't easy to get a change into the JDK. The bug report has to be processed first and converted into an issue. Someone has to see it and help with integration. PR is usually the last step in the chain. (can take a while)

[eirikbakke]

It might be possible to work around the issue from NetBeans now that we know more about the underlying cause thanks to @xxDark's investigation.

Here is one attempted workaround, which would be useful if others could test: #8277

(Myself, I don't have an easy way to test the workaround, as I was never able to reproduce the bug reliably.)

[mbien]

btw an easy way to test JDK modifications is to use --patch-module. A JVM agent is a bit overkill for things like this (and it adds an additional indirection layer).

• put cb_patch.jar somewhere, e.g the extracted netbeans folder (jar contains only the modified classes)
• start NB with .\bin\netbeans.exe "-J--patch-module=java.desktop=cb_patch.jar"

I uploaded a slightly modified build of @xxDark patch. The only difference is that it will print

### patched clipboard loaded ###

to console when the class is loaded during NB startup. (built with JDK 21 but it should work with JDK 23 too).

sha512sum cb_patch.jar
0cc9c488f512cd262676043b34c7ca59a58bd47d8cd4a4d867ff5b70e699ad4f2b9ded59eb6a9b80130b20378a492daa73b6da053a10f20211f190adf61fe219

Also: don't put random jars into your classpath, feel free to build it yourself or decompile it.

(Myself, I don't have an easy way to test the workaround, as I was never able to reproduce the bug reliably.)

same - all I can say is that it copies things in my test VM just like it did before ;)

[xxDark]

btw an easy way to test JDK modifications is to use --patch-module. A JVM agent is a bit overkill for things like this (and it adds an additional indirection layer).

* put `cb_patch.jar` somewhere, e.g the extracted netbeans folder (jar contains only the modified classes)

* start NB with `.\bin\netbeans.exe "-J--patch-module=java.desktop=cb_patch.jar"`

I uploaded a slightly modified build of @xxDark patch. The only difference is that it will print

### patched clipboard loaded ###

to console when the class is loaded during NB startup. (built with JDK 21 but it should work with JDK 23 too).

Also: don't put random jars into your classpath, feel free to build it yourself or decompile it.

(Myself, I don't have an easy way to test the workaround, as I was never able to reproduce the bug reliably.)

same - all I can say is that it copies things in my test VM just like it did before ;)

While this works, --patch-module is "I know what I'm getting myself into, it is up to me if the class change". Currently cb_patch.jar is compiled for JDK 21, so it won't work for older JDKs which NetBeans support (11, 17, etc). Moreover, it patches classes that are not a part of the public API, so there is even more room for things to break (some native methods gets added, that is package-private, etc, field added/removed and so on). IMO using a java agent for a case like this is better because this avoids all the issues with --patch-module. --patch-module is kind of like --enable-preview in a sense that you tie yourself to a specific version and build of the JDK. Basically same issues that old -Xbootclasspath had. -X options are not AFAIK a part of a supported option set. java -X: These extra options are subject to change without notice.. So I'm not sure how --patch-module is a supported option either.

[mbien]

this is exclusively meant for testing purposes since building JDKs on windows takes a while. It is fairly unlikely that we will start patching JDKs or use agents to rewrite bytecode in releases.

[wumpz]

@xxDark Reading your message I assume you started Netbeans Java in a C++ Debugger. Could you be more specific on that? Did you use Visual Studio and stuff? Or was it enough to simply debug the Netbeans starter exe?

[xxDark]

@xxDark Reading your message I assume you started Netbeans Java in a C++ Debugger. Could you be more specific on that? Did you use Visual Studio and stuff? Or was it enough to simply debug the Netbeans starter exe?

Hi. I've used Intellij's debugger and attached to NetBeans (added jdwp arguments in netbeans.conf). I've made a pull request in OpenJDK to address the issue. As for some C++ code, I've built modified OpenJDK to see whats happening

[johntor]

in version 24 using -J-Dorg.netbeans.NbClipboard.level=FINEST i had very limited problems.
In version 25 clipboard is unusable!!!

I run CopyPasteTest and here are the results

`
Iteration 1: 2025-02-23 16:07:07.627 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 1: 2025-02-23 16:07:08.557 - Pasted into Notepad

Iteration 2: 2025-02-23 16:07:09.364 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 2: 2025-02-23 16:07:10.284 - Pasted into Notepad

Iteration 3: 2025-02-23 16:07:11.077 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 3: 2025-02-23 16:07:11.995 - Pasted into Notepad

Iteration 4: 2025-02-23 16:07:12.788 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 4: 2025-02-23 16:07:13.709 - Pasted into Notepad

Iteration 5: 2025-02-23 16:07:14.499 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 5: 2025-02-23 16:07:15.478 - Pasted into Notepad

Iteration 6: 2025-02-23 16:07:16.268 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 6: 2025-02-23 16:07:17.310 - Pasted into Notepad

Iteration 7: 2025-02-23 16:07:18.100 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 7: 2025-02-23 16:07:19.144 - Pasted into Notepad

Iteration 8: 2025-02-23 16:07:19.937 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 8: 2025-02-23 16:07:20.981 - Pasted into Notepad

Iteration 9: 2025-02-23 16:07:21.774 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 9: 2025-02-23 16:07:22.812 - Pasted into Notepad

Iteration 10: 2025-02-23 16:07:23.603 - Pasted into NetBeans - Error: Copied or pasted text is empty.

Iteration 10: 2025-02-23 16:07:24.648 - Pasted into Notepad
`

I tried with and without
-J-Dorg.netbeans.NbClipboard.level=FINEST

Nothing changed...

Any idea suggestions?

[neilcsmith-net]

First suggestion - this is likely fallout from the disabled SecurityManager. For NB 25 try changing the conf from -J-DTopSecurityManager.disable=true to -J-DTopSecurityManager.disable=false -J-Djava.security.manager=allow. Report back if this doesn't get you back to the behaviour of NB24 as this would suggest something else is going on.

Second suggestion - make sure to test release candidates during the month before release! This will be more important for NB26 as the security manager is now removed, and the above fallback will not work.

[johntor]

I can confirm that adding

-J-DTopSecurityManager.disable=false -J-Djava.security.manager=allow

Seems to solve the issue. Although I had a strange crash of Netbeans.

I'm going to work for a few hours and I report if something comes up.

Thank you!

[ebresie]

Given the security manager observation...is it possible this problem has been caused by some lack of properly configured security setting (i.e., restricting copy-paste type of activity)?

Like "permission java.awt.AWTPermission "accessClipboard";" as mentioned here?

https://askubuntu.com/questions/42122/cant-copy-from-clipboard-to-any-java-applet

Granted once Security Manager is removed this may be a moot point...

[eirikbakke]

@ebresie The bug is very timing-dependent; in the past, changing the logging level is known to have "fixed" it. So changes in the security manager may simply have changed the timing slightly, rather than being an underlying problem.

[wumpz]

Thinking about the latest findings (@xxDark) I find it strange that the clipboard seems to be not useable using the Java Editor but nearly without any problems from the Output or IDE Log windows.
IMHO there is something wrong with some Java Editor special transfer flavors. Right?

[xxDark]

Output or IDE Log windows

Can you elaborate on what "IDE log windows" you are talking about?

IMHO there is something wrong with some Java Editor special transfer flavors. Right?

Well yes, but no. The problematic code is only executed if there are any flavor listeners attached to the clipboard. But you can never be sure in a such big application as NetBeans whether something won't register a flavor listener even if all usages of them are removed from NetBeans. So I don't think that trying to get rid of use of flavor listeners is a feasible approach (although it will probably "fix" the issue (or at least make it disappear)).

[wumpz]

If you build a project, then there all log stuff goes:

So simply a text/plain flavor, while the java editor seems to integrate a more specialized code flavor.